Своя CMS или WordPress: когда самопис оправдан
Спор «готовая CMS против своего движка» обычно ведут на уровне вкусов. А решается он арифметикой: сколько стоит владение системой за три года и какие риски вы готовы взять на себя. Разбираю обе стороны честно — включая то, где самопис проигрывает.
Сразу расставлю позиции, чтобы не выглядело рекламой собственного подхода: у меня есть своя CMS, и я всё равно считаю, что большинству бизнесов она не нужна. Готовое решение закрывает типовые задачи быстрее и дешевле. Вопрос в том, что делать, когда задача перестаёт быть типовой.
Стоимость владения, а не цена запуска
Главная ошибка в этом выборе — сравнивать цену старта. Готовая CMS почти всегда дешевле на входе, это очевидно и неинтересно. Считать нужно три года владения:
| Статья расходов | Готовая CMS | Свой движок |
|---|---|---|
| Запуск | Дешевле: тема и плагины уже есть | Дороже: всё пишется под задачу |
| Лицензии и подписки | Тема, премиум-плагины, продления ежегодно | Нет |
| Обновления | Регулярно и обязательно, иначе дыры | Только когда нужно вам |
| Совместимость | Обновление плагина ломает другой плагин | Ломаться нечему — зависимостей нет |
| Нетиповая доработка | Дорого: борьба с чужой архитектурой | Дёшево: код ваш, делайте что хотите |
| Найти исполнителя | Легко, специалистов много | Сложнее: нужен тот, кто разберётся в коде |
Последняя строка — главный риск самописа, и его нельзя обходить молчанием. Готовую CMS знают тысячи разработчиков; ваш собственный движок знает один человек. Это лечится документацией и понятной архитектурой, но лечится не бесплатно.
Безопасность: чужой код с правами на вашу базу
Популярные CMS взламывают не потому, что они плохо написаны, а потому что они популярные: одна найденная дыра в распространённом плагине открывает сразу десятки тысяч сайтов, и это ценная цель для автоматических сканеров. При этом уязвимость обычно не в ядре, а в дополнениях, которые ставились «на пару дней попробовать» и остались навсегда.
У самописной системы этой поверхности атаки нет, но появляется другая: ошибки собственного кода никто за вас не найдёт и не исправит. Здесь всё зависит от того, насколько аккуратно написано — например, работа с базой через подготовленные запросы, экранирование вывода, проверка загружаемых файлов и прав доступа.
Когда готовая CMS — правильный ответ
- Задача типовая. Сайт услуг, блог, небольшой магазин, портфолио — всё это давно решено и не требует изобретательства.
- Контент ведёт не разработчик. Нужна привычная админка, роли, черновики, медиатека.
- Важна взаимозаменяемость подрядчиков. Если исполнитель уйдёт, замену найдут за неделю.
- Нужно быстро. Запуск за считанные дни готовая система обеспечит, разработка с нуля — нет.
- Экосистема закрывает интеграции. Оплата, доставка, рассылки — готовые модули дешевле собственной реализации.
Когда свой движок начинает окупаться
- Процесс нестандартный. Когда бизнес-логика не ложится в «товар-корзина-заказ», подгонка готовой системы стоит дороже, чем написать своё.
- Сайтов много и они однотипные. Сеть проектов из одной панели — тот случай, когда собственная платформа экономит недели на каждом запуске.
- Критична скорость и вес. Своя система тянет ровно то, что нужно этой странице, а не всё сразу.
- Нужен полный контроль. Никаких сюрпризов от обновлений, никакой зависимости от планов чужой команды.
- Продукт — сам движок. Если система будет использоваться на многих проектах, разработка амортизируется.
Как выглядит своя CMS, когда её пишут ради дела
Мой движок CAMELIO сделан ровно под сценарий «много однотипных сайтов, запускать быстро, хостинг любой». Отсюда и решения: чистый PHP без Composer и Node, чтобы ставилось куда угодно; одна кодовая база под MySQL и SQLite; блочный конструктор страниц; система тем папками; SEO-разметка и мгновенная индексация в ядре, а не плагином.
Что важнее списка возможностей: каждое из этих решений — ответ на конкретную боль, а не «хотелось написать свою CMS». Если у вас таких болей нет — берите готовое, и это будет честный профессиональный совет, а не отговорка.
Как принять решение без религиозных войн
Три вопроса, которые обычно закрывают спор:
- Кто и как часто будет менять контент? Если не разработчик — нужна нормальная админка, и это перевешивает многое.
- Есть ли в задаче что-то, чего нет в типовых решениях? Если нет — вопрос закрыт, берите готовое.
- Что будет, если через год исполнитель пропадёт? На этот вопрос должен быть внятный ответ при любом выборе: документация, доступы, понятный код, возможность передать проект.
И отдельно — про доступы. Независимо от того, что вы выбрали: домен, хостинг и репозиторий должны быть оформлены на вас. Это не про недоверие, это гигиена. Подробнее — в статье о выборе разработчика.
Не знаете, что выбрать под свою задачу?
Опишите, что должен уметь сайт и кто будет его вести — скажу прямо, нужен ли тут отдельный движок или задача закрывается готовым решением за неделю.
Пример того, как выглядит своя CMS на практике — разбор архитектуры CAMELIO: блочный конструктор, темы, SEO из коробки, ноль внешних зависимостей.