Выбор CMS или собственной разработки без дорогих переделок сайта

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

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

Главный вопрос не «CMS или кастом», а «какие обязательные сценарии мы не имеем права потерять».

Пожелания собираются десятками, но для выбора важны не все идеи, а сценарии, без которых бизнес не может продавать, обслуживать или выполнять обязательства.

Контент: кто публикует страницу, меняет цену, загружает документ, согласует изменение и откатывает ошибку? Продажи: нужны ли остатки, индивидуальные цены, спецификации, платежи, статусы заказа, обмен с CRM или учётной системой? Права и данные: можно ли выгрузить пользователей, файлы, историю заказов, формы; кому принадлежат домен, облако и лицензии? Эксплуатация: как выходят обновления, кто отвечает за уязвимости, есть ли тестовый контур и рынок специалистов?

Fit-gap — проверка соответствия: готовая платформа закрывает сценарий без доработки, через расширение, требует собственной разработки или не подходит.

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

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

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

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

Не нужен фиктивный калькулятор на три года. Для каждого варианта полезнее назвать неизвестности и владельца: экспорт заказов подтверждён демонстрацией, стоимость лицензии фиксируется договором, восстановление не проверено, правила скидок не формализованы. Неопределённость тоже часть TCO.

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

Готовая платформа также может запереть бизнес, если данные нельзя выгрузить, аккаунт принадлежит подрядчику, а лицензия оформлена на чужую компанию.

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

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

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

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

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

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

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

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

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

Например, компания хочет B2B-каталог, персональные цены и кабинет. Если персональные цены пока живут в Excel, а статусы заказов расходятся между CRM и учётной системой, сначала можно построить каталог и расчётный запрос, а не кабинет с недостоверными данными. Если правила цен оформлены и их источник понятен, интеграция становится проверяемой частью первого релиза. Это не «урезание мечты», а защита проекта от дорогой имитации готовности.

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

Для трёх-пяти критичных сценариев попросите демонстрацию на похожих данных либо небольшой технический прототип. Пройдите путь не от панели администратора, а от действия пользователя до нужного результата: клиент отправляет конфигурацию, менеджер видит её в CRM, данные не теряют идентификатор, редактор меняет правило без правки кода, система корректно сообщает об ошибке. Результат фиксируйте в fit-gap как подтверждённый, частично подтверждённый или неподтверждённый.

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

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

Особенно важно назвать зависимость от закрытого компонента. Если критичная функция работает на коммерческом модуле, облачном API или продукте одного поставщика, документ должен отвечать: кто оплачивает лицензию, что будет при изменении тарифа, можно ли выгрузить данные, как технически отключить зависимость и сколько стоит замена. Не каждая зависимость плоха; плоха та, которую бизнес обнаруживает после того, как построил вокруг неё процесс.

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

Технологическое решение нельзя передать на утверждение только разработчику или только маркетологу. Коммерческий руководитель подтверждает сценарии продажи, операционный — исключения и данные, маркетинг — контент и привлечение, ИТ — поддержку и безопасность, а руководитель проекта фиксирует компромиссы. Когда один из участников появляется после запуска, он почти всегда приносит «новое требование», которое на самом деле было старым обязательным сценарием.

До договора составьте лист допущений: что система будет делать в первом релизе, что не будет, какие данные готовы, какие интеграции требуют обследования и кто принимает результат. Это не бюрократия ради ТЗ. Так бизнес отличает осознанно отложенную функцию от обещания, которое случайно выпало из сметы.

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

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

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

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

Хороший фундамент не отменяет сложные решения, а делает их видимыми до того, как они становятся дорогими переделками.

Техническую сторону обмена полезно проверить через понятный контракт API между системами, а готовность сценариев — в материале «Когда нужен личный кабинет».