В прошлом году к нам пришел производитель оборудования с запросом: «нужно просто сделать сайт для партнеров». На старте ожидание было 700-900 тыс. ₽: каталог, форма входа, несколько страниц. Но уже через пару встреч с продажами и бэк-офисом стало понятно, что нужны 4 роли, персональные цены, документы, статусы отгрузок, повторные закупки и обмен с 1С. В итоге MVP вышел на 3,5-4 млн ₽.
Это нормальная история. Проблема обычно не в смете, а в том, что бизнес называет платформу сайтом и замечает разницу слишком поздно.
Все меняется в тот момент, когда «сайт» должен обслуживать процесс
Обычный сайт решает понятную задачу: рассказать о продукте, привести заявку, иногда принять оплату. Платформа устроена иначе: в ней пользователь работает. Он смотрит свои данные, скачивает документы, повторяет заказ, согласует действия, отслеживает статусы.
На пресейле у нас часто бывает короткий диалог:
- Нам нужен сайт для клиентов.
- Что клиент должен делать после входа?
- Видеть свои цены, акты, статусы заказов и повторять закупку.
- Тогда речь уже о кабинете с бизнес-логикой.
Если пользователь должен не просто читать, а выполнять действия по правилам бизнеса, вы почти наверняка обсуждаете платформу.
У нас был проект в дистрибуции, который внутри компании называли «сайтом для дилеров». По факту там были нужны прайсы по договору, остатки, рекламации, документы отгрузки и согласование заказа менеджером. Разница с обычным сайтом по бюджету оказалась почти в 6 раз.
Цена растет не от экранов, а от логики под ними
Я много раз видел два внешне похожих продукта: меню, каталог, карточка, кабинет. Один собирается на CMS за разумные деньги. Второй требует Laravel 11 или Node.js 20 + NestJS, PostgreSQL 16, очереди, API, аудит действий и отдельную админку. Визуально разница почти не читается.
Короткая формула здесь простая: страницы стоят недорого, а сценарии и данные - дорого.
| Что внутри | Сайт | Платформа |
|---|---|---|
| Пользователи | 1-2 роли | 3+ ролей |
| Основной сценарий | контент, заявка | работа с заказами и данными |
| Бэкенд | CMS, формы | права, статусы, API, журналы |
| Интеграции | иногда CRM | 1С, ERP, CRM, склад |
| Админка | простая | отдельная под операции |
Сильнее всего бюджет двигают вещи, которых нет на макете: кто что видит, кто что подтверждает, где хранится история, что происходит при ошибке обмена, как система ведет себя при росте нагрузки. Проект с 20 экранами, 4 ролями, 12 сценариями и 6 интеграциями легко будет стоить в 3-6 раз дороже, чем «такой же по дизайну» сайт.
Какой вопрос задать подрядчику первым?
Спросите не «сколько стоит сайт», а «что пользователь делает после входа и какие действия система снимает с людей». После этого слово «сайт» часто исчезает само.
Платформа окупается там, где команда повторяет одно и то же вручную
Если менеджеры копируют данные из Excel, отвечают по статусам в Telegram, вручную отправляют документы и каждый раз сверяют цены, бизнес уже платит за отсутствие системы. Эти расходы просто спрятаны в зарплатах, ошибках и задержках.
В сервисной компании, с которой мы работали, менеджер тратил 3-4 часа в день на письма, согласования и закрывающие документы. Мы собрали кабинет клиента на Laravel 11, PostgreSQL 16 и связали его с amoCRM. Через 9 недель ручная работа сократилась на 67 часов в месяц, а число ошибок в документах снизилось на 34%.
Можно ли сначала сделать сайт, а потом дорастить?
Можно, если архитектура изначально это допускает. Если нет, через 6-18 месяцев вы оплачиваете миграцию данных, переделку логики и паузу в развитии.
Дешевый старт иногда обходится дороже
Мы пробовали путь «сначала быстро запуститься, потом развивать». Иногда он работает. Но если уже на старте понятны роли, документы, согласования и интеграции, временное решение быстро превращается в дорогой костыль.
Был и неудачный кейс. Оптовая компания выбрала типовой интернет-магазин, чтобы уложиться в 1,2 млн ₽ и выйти за 10 недель. Через 8 месяцев понадобились персональные цены дилеров, кабинет менеджера, архив документов и обмен с 1С. Типовая структура этого не выдержала: часть логики сделали обходными путями, часть процессов команда продолжала вести вручную, а потом все равно пришла к переносу на новую систему.
Когда траектория роста уже видна, мы предпочитаем сразу проектировать ядро: сущности, роли, модель данных, API, будущие расширения. Не писать все сразу, а заложить основу. По опыту это дешевле, чем потом разбирать систему, которая ломается при каждом новом сценарии.
На какой бюджет смотреть без самообмана
Для первого ориентира мне хватает трех вопросов:
- кто будет пользоваться продуктом каждый день;
- какие операции он должен забрать у менеджеров;
- какие интеграции точно появятся в ближайший год.
Если ответы простые, обычно хватает сайта или стандартного магазина. Если уже звучат «личный кабинет», «свои цены», «документы», «статусы», «1С», «разные права», стоит смотреть на MVP платформы, а не на редизайн.
По вилкам в 2026 году я бы ориентировался так:
- корпоративный сайт - 400-900 тыс. ₽
- интернет-магазин со стандартной логикой - 900 тыс. - 2,5 млн ₽
- MVP B2B-платформы или кабинета - 2,5-6 млн ₽
- полноценная платформа - 6-15+ млн ₽
В ближайшие 6-12 месяцев бюджеты будут все сильнее делиться по одному признаку: продукт показывает информацию или двигает операцию. Кто продолжит покупать «просто сайт» для сложного процесса, почти наверняка заплатит дважды.
