Фреймворк нужен, когда нестандартная логика — ядро продукта, а не отдельная функция сбоку. Если большая часть сценариев сайта не помещается в готовую CMS, дешевле написать систему целиком. Если мешает один участок, его выносят отдельным сервисом, а сайт оставляют на CMS: такой вариант почти всегда дешевле полной пересборки.
Что посчитать перед решением
- Доля нестандартных сценариев. Выпишите всё, что должен делать сайт, и отметьте, что закрывается готовыми средствами, а что придётся писать. Пропорция и есть ответ.
- Режим интеграций. Разовый обмен файлами и постоянная синхронизация с несколькими системами — задачи разного класса по сложности и стоимости поддержки.
- Кто дорабатывает. Если после запуска сайт меняется каждый месяц силами разработчиков, архитектура важнее готовых модулей.
- Что будет при росте. Рост числа пользователей, заказов или объёма данных проверяет архитектуру сильнее, чем запуск.
- Насколько дорого ошибиться. Если простоит сайт услуг — это потеря заявок на неделю. Если встанет сервис, через который идут заказы, счёт другой.
Что дешевле фреймворка
Навести порядок в CMS
Иногда узкое место не в платформе, а в обвязке: множество модулей, часть которых дублирует друг друга, ненастроенный кэш, тяжёлые страницы. Ревизия и чистка стоят часы, а не месяцы, и часто снимают большую часть проблем. После разбора выясняется, что часть «ограничений платформы» была следствием захламления, а не её возможностей.
Вынести один участок
Если нестандартная часть одна (расчёт, интеграция, обмен), её делают отдельным сервисом, который общается с сайтом по API. CMS продолжает работать как обычно, а сложный участок получает нормальную архитектуру и тесты.
Заменить проблемный узел
Бывает, что мешает конкретное решение: неудачный модуль оплаты, старый обмен, самописная надстройка. Замена этого узла обходится дешевле, чем переносить весь сайт на другую технологию.
Этапы разработки сайта
Бриф
задачи, аудитория, рамки бюджета
Оценка
состав работ, сроки, вилка цен
Прототип
структура страниц и сценарии
Дизайн
макеты страниц и мобильных версий
Сборка
вёрстка, платформа, интеграции
Контент
тексты, изображения, наполнение каталога
Тестирование
устройства, формы, скорость, аналитика
Передача
обучение, доступы, месяц сопровождения
Сколько стоит проект на фреймворке
Здесь всё пишется под задачу, поэтому сроки измеряются месяцами: готовая платформа даёт админку и типовые механизмы сразу, на фреймворке их проектируют. Работы считаются по часам: от 2 000 ₽ за час; смета складывается из числа сценариев, ролей и интеграций и фиксируется до старта. Поддержка после запуска идёт отдельной строкой: сложную систему сопровождают по договору, а не разовыми правками, ставка та же, часы считаются по факту. Разборы конкретных случаев есть в статье Laravel или WordPress.
Как распознать фреймворк ради фреймворка
- Исполнитель предлагает фреймворк до разбора задачи и не может назвать сценарии, которые не помещаются в CMS.
- В смете нет этапа аналитики: без описания процессов стоимость такой системы посчитать нельзя.
- Преимущества описывают общими словами про гибкость, не называя конкретных ограничений текущей платформы.
- Не обсуждается, кто будет сопровождать код через год и как его передадут другой команде.
Что остаётся у вас после запуска
Код, документация, доступы к серверу и репозиторию. Сопровождать систему может команда, знакомая с выбранным фреймворком: специального доступа через вендора не требуется, код понятен любому специалисту на PHP. Если своей команды нет, поддержку берут по договору: программирование и доработка по часам, с оценкой задачи до начала работ.
Передачу стоит оговорить в договоре: доступы, репозиторий и документация переходят в момент сдачи проекта, а не по запросу через год. Это обычная практика, и она снимает главный риск сложных проектов — зависимость от одного исполнителя.
Когда ответ — фреймворк не нужен
Так бывает чаще, чем кажется: сайт услуг, корпоративный сайт, магазин с типовыми сценариями закрываются готовыми решениями. В этих случаях фреймворк добавляет месяцы работ, а выигрыш остаётся теоретическим. Разбор задачи стоит дешевле, чем проект не на той технологии, поэтому мы говорим об этом до сметы, а не после запуска.
Проверить это можно и самостоятельно: попросите исполнителя перечислить сценарии, которые нельзя реализовать на готовой CMS. Если список короткий и закрывается доработками, фреймворк не окупится.
Частые вопросы
Как понять, что проблема в платформе, а не в исполнении
Спросите, какие именно ограничения платформы мешают и что уже пробовали. Если речь о кривом коде, медленных запросах или беспорядке в модулях, поможет ревизия, а не новый фреймворк. Платформенные ограничения настройкой не обходятся.
Решит ли фреймворк проблему скорости
Сам по себе нет. Скорость определяется архитектурой, запросами к базе и кэшированием: неудачно спроектированная система на фреймворке работает медленнее настроенной CMS. Ждать от смены технологии мгновенного ускорения не стоит.
Сколько времени занимает проект на фреймворке
Ориентир — месяцы. Работа идёт итерациями, первая версия появляется раньше финала, но запуск позже, чем на готовом решении: часть времени уходит на проектирование, тесты и перенос данных.
Что делать, если разработчики ушли, а система осталась
Передать новой команде доступы, код и документацию. Фреймворк — общий инструмент, специалистов на рынке достаточно; сложность обычно в документации, которой пренебрегли при разработке. Если своей команды нет, сопровождение берут на техническую поддержку.
Влияет ли выбор фреймворка на результат
Меньше, чем архитектура и команда. На PHP распространены Laravel и Symfony, специалистов по ним достаточно. Важнее, чтобы исполнитель работал на том, что знает глубоко, и оставил документацию. Тогда систему сможет сопровождать кто угодно.