Свой движок или CMS: как посчитать стоимость владения

Собственный движок может стоить дороже CMS уже в первый год, но готовая система иногда проигрывает на горизонте трёх лет из-за обновлений, плагинов и ручной поддержки. Сравнивать нужно не цену лицензии, а TCO — полную стоимость владения: разработку, инфраструктуру, безопасность, исправление ошибок и работу команды.

Почему сравнение «бесплатно против дорого» не работает

У CMS обычно низкий порог запуска: вы устанавливаете WordPress 6.x, подключаете тему, добавляете плагины и получаете рабочий сайт. У собственного движка почти всегда есть заметные расходы до первого релиза: проектирование, backend, frontend, админ-панель, тестирование, деплой.

Но цена запуска — только первая строка сметы. CMS переносит часть расходов на период эксплуатации. Плагины нужно обновлять, совместимость проверять, уязвимости закрывать, а нестандартные функции иногда приходится встраивать обходными путями. Свой движок переносит расходы в разработку и поддержку ядра.

Правильный вопрос звучит не «что дешевле построить», а «за что команда будет платить каждый месяц после запуска».

Примечание. TCO (Total Cost of Ownership) — совокупные расходы на владение системой за выбранный период, включая не только покупку или разработку, но и эксплуатацию, изменения и вывод из эксплуатации.

Какие расходы нужно включить в расчёт

Зафиксируйте период: для небольшого сайта достаточно 24 месяцев, для интернет-магазина или внутренней платформы лучше считать 36 месяцев. Все ставки подставляйте свои: зарплаты, стоимость часа подрядчика, серверов и сервисов. Универсальной рыночной цифры здесь нет.

Разработка и запуск

• аналитика требований и проектирование архитектуры;
• вёрстка, backend, админ-панель и роли пользователей;
• перенос данных, настройка поиска, интеграции с оплатой, CRM и доставкой;
• тестирование, резервное копирование, мониторинг и процедура отката;
• обучение контент-менеджеров и подготовка документации.

Для CMS часть работ уже выполнена разработчиками платформы. Но это не означает нулевую стоимость: подбор темы, настройка расширений и устранение конфликтов тоже занимают часы.

Ежемесячная эксплуатация

• хостинг, база данных, объектное хранилище, CDN и резервные копии;
• обновление ядра, темы, модулей и зависимостей;
• проверка после обновлений и исправление регрессий;
• мониторинг доступности, ошибок и заполнения дисков;
• техническая поддержка редакторов и администраторов.

У собственного движка к инфраструктуре добавляется ответственность за фреймворк, библиотеки, миграции базы данных и внутренние инструменты. У CMS отдельной строкой появляется аудит совместимости расширений.

Цена изменений

Составьте список функций, которые появятся после запуска. Например: личный кабинет, несколько складов, импорт из ERP, мультиязычность, разные цены для групп клиентов. Оцените каждую функцию отдельно в часах и умножьте на вашу стоимость часа.

У CMS простая функция может стоить дёшево, пока укладывается в возможности ядра и готовых расширений. После пересечения этой границы цена растёт: придётся писать собственный модуль, менять шаблоны, поддерживать fork или отказываться от обновлений. В собственном движке нет ограничений конкретной CMS, но каждую базовую возможность нужно разработать и тестировать.

Модель расчёта на 24 или 36 месяцев

Используйте две отдельные формулы. Они помогают не смешать разовые затраты с регулярными.

TCO CMS = запуск + миграция + ежемесячная эксплуатация × число месяцев + плановые изменения + внеплановые исправления.

TCO собственного движка = проектирование и разработка + запуск + ежемесячная эксплуатация + поддержка ядра × число месяцев + плановые изменения + внеплановые исправления.

В строке «внеплановые исправления» не подставляйте ноль. Если данных нет, посчитайте два сценария: базовый и стрессовый. В стрессовом добавьте несколько рабочих дней на несовместимое обновление, сбой интеграции или восстановление после ошибки. Это не прогноз, а проверка устойчивости бюджета.

Что обычно забывают посчитать

Расширения и несовместимость

В CMS стоимость плагина — не всегда его цена в каталоге. Добавьте время на выбор, проверку разработчика, резервную копию, тестовый стенд и проверку обновлений. Если расширение критично для оплаты или заказов, учтите запасной вариант на случай, когда автор прекратит поддержку.

Нельзя автоматически считать собственный модуль дешевле. Он не требует платы третьей стороне, но его авторизация, логирование, тесты и документация остаются на вашей команде.

Безопасность и восстановление

Для CMS проверьте, кто отвечает за обновление ядра и кто получает уведомления об уязвимостях расширений. Для собственного движка добавьте инвентаризацию зависимостей, регулярное обновление библиотек, проверку прав доступа и тест восстановления из резервной копии.

Резервная копия без проверенного восстановления — не полноценная мера защиты. В смете нужны часы на тест, отдельное хранилище и понятная инструкция для дежурного.

Зависимость от людей

У CMS проще найти специалиста на типовую задачу, но знание конкретной сборки всё равно важно. У собственного движка риск выше: один разработчик может знать нестандартную архитектуру, миграции и неочевидные ограничения. Посчитайте передачу проекта другому человеку как отдельную задачу.

Когда CMS выигрывает

Выбирайте готовую CMS, если требования укладываются в её модель контента, ролей и шаблонов, а главная ценность проекта — скорость публикации. Это типичный сценарий для корпоративного сайта, блога, каталога с умеренной логикой и магазина без сложного ценообразования.

CMS также разумнее, если команда небольшая и у неё нет постоянного backend-разработчика. Но проверьте не только список функций, а способ их изменения. Функция, которую нельзя безопасно обновлять без ручного редактирования ядра, увеличивает будущий TCO.

Когда собственный движок оправдан

Свой движок имеет смысл, если бизнес-процесс плохо совпадает с моделью CMS: сложные статусы, расчёты, права, высокая нагрузка, несколько каналов продаж или требования к изоляции данных. В этом случае готовая платформа может потребовать столько обходных решений, что преимущество быстрой установки исчезнет.

Решение оправдано только при наличии команды, которая сможет поддерживать ядро несколько лет. Если разработка — разовый проект без владельца после запуска, собственный движок превращается в технический долг с высокой стоимостью смены подрядчика.

Как найти точку окупаемости

Сначала посчитайте разницу в цене запуска, затем ежемесячную разницу поддержки. Если собственная разработка дороже на 2 000 000 рублей, но экономит 150 000 рублей в месяц, теоретическая точка окупаемости — около 14 месяцев. Это упрощённая модель: она не учитывает стоимость денег, задержку запуска, риски и незапланированные работы.

Добавьте стоимость задержки. Если собственный движок запускается на четыре месяца позже и каждый месяц проект приносил бы 300 000 рублей маржи, в расчёт нужно включить ещё 1 200 000 рублей упущенной маржи. Это не расход разработки, но реальная цена выбранного пути.

Отдельно посчитайте сценарий роста. Если через год появятся мобильное приложение, партнёрский API или второй регион, CMS может потребовать дорогой переделки. Собственный движок может справиться лучше, но только если нужные границы заложили в архитектуру, а не просто написали больше кода.

Что ломается первым

• CMS: обновление расширения меняет структуру данных или ломает шаблон;
• CMS: критичная функция зависит от одного плагина без понятной замены;
• собственный движок: документация отстаёт от кода, и новый разработчик не может безопасно внести изменение;
• собственный движок: тесты покрывают бизнес-логику, но не миграции, права и восстановление;
• оба варианта: нет владельца обновлений, мониторинга и регулярной проверки резервных копий.

Если выбор зависит от будущей нагрузки, не подставляйте прогнозные цифры без замеров. Проведите тест на вашей конфигурации: размер базы, число одновременных запросов, доля чтения и записи, работа поиска и внешних интеграций. Результаты сохраните вместе со сметой.

Что сделать дальше

1. Зафиксируйте функции первого релиза и отдельный бэклог на 36 месяцев.
2. Для каждого пункта укажите: есть ли он в CMS, нужна ли доработка, кто будет поддерживать результат.
3. Составьте две сметы по одной формуле и в одинаковых ставках команды.
4. Добавьте стрессовый сценарий: задержка запуска, смена подрядчика, несовместимое обновление и восстановление из резервной копии.
5. Перед решением проведите короткий технический эксперимент: реализуйте одну самую нестандартную функцию в CMS и оцените её поддержку, а не только первый результат.

После выбора поставьте на контроль три показателя: часы на обновления, время устранения инцидентов и стоимость каждой крупной функции. Через три месяца сравните их с первоначальной моделью TCO. Именно это покажет, оказался ли выбор выгодным, а не размер стартовой сметы.