Три варианта, а не два
Когда говорят «CMS или готовая платформа», обычно имеют в виду выбор между своим сайтом и конструктором. На практике вариантов три: SaaS-конструктор, CMS с плагинами и собственная разработка, включая headless-подход, когда контент хранится отдельно, а страницы собираются на его основе.
Разница между ними не в «современности», а в том, кто отвечает за поддержку и насколько легко вы можете уйти. Конструктор держит вас на своей платформе, CMS с плагинами зависит от экосистемы расширений, своя разработка зависит от вашей команды или подрядчика.
Поэтому выбор начинают не с технологий, а с ответа на вопрос: кто и что будет менять на сайте через месяц после запуска.
Вопросы, которые определяют выбор
Ответьте на несколько вопросов до разговора с подрядчиком. Они отсекают большинство неподходящих вариантов быстрее, чем сравнение длинных списков возможностей.
Если на часть вопросов ответа нет, это и есть первый этап работы: сначала описание процессов, потом выбор системы.
- Кто редактирует контент: вы сами, маркетолог, подрядчик
- Сколько типов контента: страницы, статьи, товары, вакансии, кейсы
- Нужен ли каталог с фильтрами и остатками
- Нужен ли личный кабинет и роли пользователей
- Какие интеграции обязательны в первый год работы
- Кто будет обновлять систему и разбираться со сбоями
- Есть ли требование хранить данные на своей стороне
Когда оправдана готовая платформа
Конструктор или SaaS-платформа оправданы, когда задача типовая, бюджет ограничен, а контент нужно менять часто и без разработчика. Лендинг под рекламу, визитка, небольшая страница услуги — как раз этот случай.
Ограничения проявляются при росте: нестандартная логика каталога, свои правила расчёта доставки, нетиповые формы, глубокая интеграция. Платформа делает типовое быстро, а нестандартное — дорого или никак.
Отдельно проверьте, что будет с сайтом, если вы решите уйти: можно ли выгрузить контент в удобном виде, сохранятся ли адреса страниц, не окажется ли, что часть данных живёт только внутри платформы.
И ещё один практический критерий: скорость правки. Если маркетологу нужно поменять заголовок, а он каждый раз пишет в поддержку, вы платите за простой. Проверяется это просто — попросите внести правку на демо-доступе и засеките, сколько шагов для этого нужно.
Когда CMS с плагинами
CMS с плагинами — компромисс: вы получаете готовую админку и экосистему расширений, но принимаете правила чужой архитектуры. Это разумно, когда нужна стандартная админка и есть кому следить за обновлениями.
Главный риск — не сама CMS, а набор плагинов. Каждый сторонний модуль добавляет код, который вы не контролируете, и обязательство обновлять его вместе с системой. Чем больше модулей, тем выше шанс, что после обновления что-то перестанет работать.
Второй риск — скорость: «поставим плагин кэширования» не заменяет аккуратную вёрстку и разумную загрузку ресурсов. Если на сайте десятки расширений, оптимизация превращается в борьбу с ними.
Третий — обновления. Их нужно ставить, но каждое обновление системы или модуля требует проверки ключевых сценариев: формы, каталога, оплаты. Если такой проверки нет, обновления откладываются, и через год сайт остаётся на версии, которую уже никто не поддерживает.
Когда своя разработка или headless
Собственная разработка оправдана, когда логика нетиповая: каталог со сложными правилами, личный кабинет, нестандартные расчёты, много интеграций. Здесь вы получаете контроль над данными и скоростью, но принимаете расходы на поддержку.
Headless-подход — отдельный случай: контент живёт в удобной редакции, а страницы собираются отдельным приложением. Это даёт гибкость в интерфейсе и скорости, но требует, чтобы кто-то поддерживал обе части.
Ключевой вопрос при выборе своей разработки: кто будет вносить изменения через год. Если ответ «тот же подрядчик, потому что больше никто не разберётся», это зависимость, и её стоимость нужно понимать заранее.
Стоимость владения, а не только запуска
Сравнивать варианты по цене запуска — распространённая ошибка. У конструктора низкий вход и ежемесячная плата, у CMS — расходы на обновления и внимание, у своей разработки — высокая начальная стоимость и поддержка.
Добавьте стоимость изменений: правка блока в конструкторе делается за минуты, в собственной вёрстке — по заявке в поддержку. Если контент меняется часто, дешёвый запуск может оказаться дороже в эксплуатации.
И посчитайте стоимость выхода. Переезд с платформы на свой движок — отдельный проект с редиректами и переносом контента. Чем раньше вы это понимаете, тем спокойнее принимаете решение.
Есть и неочевидная статья расходов — внимание. Любая система требует, чтобы кто-то замечал сбои, обновления и истёкшие сроки. Если такого человека нет, выбирайте вариант с минимальным количеством движущихся частей: он прощает невнимание дольше.
Чек-лист выбора
Соберите ответы по пунктам и сравните варианты не по обещаниям, а по фактам. Просите показать админку на демо-доступе: за пять минут работы в ней видно больше, чем в презентации.
Если два варианта равны по возможностям, выбирайте тот, из которого проще уйти. Свобода выхода стоит дороже, чем ещё одна функция, которой вы, скорее всего, не воспользуетесь.
- Админка понятна вашему сотруднику без обучения на курсах
- Контент можно выгрузить в открытом формате
- Адреса страниц остаются под вашим контролем
- Есть способ делать нетиповые блоки, а не только готовые шаблоны
- Интеграции с CRM и 1С технически возможны, а не «в разработке»
- Понятно, кто и за какие деньги обновляет систему
- Есть резервное копирование и возможность откатиться
- Доступы и код принадлежат вам, а не подрядчику