Кастомная CMS для задачи, которой тесно в готовой платформе

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

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

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

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

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

Кастомной CMS нужна не уникальность ради уникальности, а повторяемая бизнес-логика, которую компания действительно собирается развивать.

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

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

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

Но даже такой проект не обязан начинаться с собственного ядра. Готовая CMS с отдельным модулем или headless-платформа может закрыть задачу дешевле. Решение принимают после прототипа данных и проверки альтернатив.

Административная панель кастомной CMS — интерфейс продукта для сотрудников. Её нельзя оставлять «на потом», считая, что внутренний пользователь потерпит. Если форма не показывает зависимость полей, не объясняет ошибку и не сохраняет черновик, компания просто переносит стоимость разработки в ежедневный труд редакторов.

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

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

Если кастомная CMS повторяет хаос компании, она автоматизирует не процесс, а хаос.

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

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

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

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

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

Репозиторий хранит исходный код и историю изменений. Компания должна иметь к нему доступ на протяжении проекта, а не получить архив в день расставания. Инструкция развёртывания объясняет, как из кода получить работающую систему. Отдельные окружения позволяют проверить изменение до выпуска.

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

Bus factor — зависимость проекта от незаменимого человека. Если только один разработчик знает выпуск и восстановление, показатель равен одному независимо от числа сотрудников в подрядчике. Снижают риск совместное владение, ревью кода, инструкции и регулярная проверка восстановления.

Фразы «быстрая», «надёжная» и «безопасная» CMS не являются критериями приёмки. ISO/IEC 25010:2023 задаёт модель из девяти характеристик качества продукта. ГОСТ Р ИСО/МЭК 25010-2015 основан на предыдущей восьмичастной модели, поэтому его перечень нельзя выдавать за актуальную редакцию. Оба документа помогают выбрать группы требований, но состав и термины нужно брать из указанной версии.

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

OWASP ASVS содержит проверяемые требования к безопасности веб-приложений. В ТЗ нужно указывать выбранную версию вместе с идентификаторами требований, потому что номера меняются между версиями. Ссылка на ASVS не доказывает соответствие: требования ещё нужно выбрать, проверить и зафиксировать. Актуальную редакцию перепроверяют перед проектом.

Готовая CMS наследует часть проверок от экосистемы; кастомная система должна доказать качество собственной реализации.

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

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

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

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

Технический контроль не заменяет договорную и правовую проверку. Для программ и баз данных разные конструкции дают разные исходные правила. Если предметом договора было создание конкретной программы или базы данных, пункт 1 статьи 1296 ГК РФ по умолчанию относит исключительное право к заказчику, если стороны не установили иное. Если создание не было прямым предметом договора, но программа появилась при его выполнении, возможна статья 1297: по умолчанию право остаётся у подрядчика, а заказчик получает предусмотренное законом использование для целей договора, если стороны не договорились иначе.

Автором может быть только гражданин. Когда исполнитель-автор сам создаёт ПО, пункт 5 статьи 1296 отсылает к договору авторского заказа по статье 1288; в нём отдельно определяют отчуждение исключительного права или лицензию. Когда подрядчик-организация привлекает своих работников, код может быть служебным произведением по статье 1295. Для заказчика важны доказательства служебного характера кода, условия между работником и работодателем, учёт возможного возврата исключительного права автору по правилам о трёхлетнем сроке, а затем — основание, по которому право принадлежит заказчику или ему предоставлено использование: статьи 1296, 1297 или условия договора. Передача репозитория, файлов или акта сама по себе не отвечает, кому принадлежит исключительное право и на каких условиях можно использовать компонент. Это не юридическая консультация: предмет реального договора, цепочку прав, отчуждение или лицензию и вознаграждение должен проверить профильный юрист.

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

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

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

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

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

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

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

Проверьте решение по пяти осям:

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

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

Минимальный список:

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

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