Ко мне регулярно приходят с запросом «нужен сайт с кабинетом». Через пару встреч в проекте уже появляются роли, статусы, история действий, обмен с 1С или amoCRM, API и очередь уведомлений. Смета в этот момент вырастает с 900 тыс. ₽ до 2,8-3,5 млн ₽, и причина обычно не в ставке команды.
Проблема в другом: бизнес называл проект сайтом, а по факту описывал внутренний сервис. Если заранее отделить полезную сложность от лишней, экономия получается не косметическая, а на месяцы и миллионы.
Граница проходит по процессу, а не по дизайну
Внешне корпоративный сайт и кабинет клиента могут выглядеть почти одинаково. Но сайт показывает контент, а приложение управляет процессом. Эта простая разница обычно и меняет бюджет в 3-6 раз.
Если в проекте есть страницы, формы, CMS и новости, он все еще ближе к сайту. Когда появляются роли, согласования, история, документы, ограничения по правам и обмен с внешними системами, начинается уже другой класс работ.
У нас был проект для дистрибутора оборудования. Клиент называл его «кабинетом для партнеров». После разбора выяснилось, что у дилеров разные цены, у менеджеров разные лимиты, заказы проходят согласование, прайсы приходят из ERP, а изменения нужно логировать. Снаружи это выглядело как аккуратный кабинет. Внутри - полноценное веб-приложение.
Авторизация уже делает проект приложением?
Нет. Один логин без состояний и сценариев почти ничего не меняет. Я обычно формулирую вопрос так: система просто открывает закрытую страницу или действительно ведет пользователя по бизнес-процессу?
Деньги сгорают в логике, данных и интеграциях
На старте чаще обсуждают дизайн и верстку, потому что это видно. По деньгам картина обычно другая: в рабочем B2B-кабинете визуальная часть часто занимает 20-30% трудозатрат, а остальное уходит в правила, данные и обмены.
| Часть проекта | Что внутри | Риск для бюджета |
|---|---|---|
| Верстка | страницы, адаптивность, UI-компоненты | низкий |
| Frontend | формы, таблицы, фильтры, состояния, работа с API | средний |
| Backend | роли, бизнес-правила, журналирование, очереди | высокий |
| БД и интеграции | связи данных, индексы, CRM, ERP, внешние сервисы | очень высокий |
На одном кабинете для сервисной компании клиент видел всего «пять экранов». После декомпозиции получилось 5 ролей, 12 сценариев, 3 интеграции, генерация PDF и история изменений. Стек был спокойный: Laravel 11, PostgreSQL 16, Vue 3. Визуально проект остался компактным, но бэкенд и БД забрали около 75% всех часов.
Сайт: страницы -> формы -> CMS
Веб-приложение: роли -> сценарии -> API -> база данных -> интеграции -> аудит действий
Короткий discovery обычно дешевле спешки
Мы тоже пробовали стартовать сразу в разработку. У меня был проект, где я согласовал MVP без нормальной схемы статусов и связей документов, и через 7 недель пришлось переделывать половину таблиц в PostgreSQL. Клиент потерял время, мы потеряли темп. Это был обычный рабочий просчет, но дорогой.
Поэтому на проектах от 2 млн ₽ я почти всегда закладываю 1-2 недели на разбор задачи. За это время обычно успеваем пройти четыре вещи:
- цель первого релиза и что в нем считается полезным результатом
- роли и 5-10 ключевых сценариев
- сущности данных и список интеграций
- прототип и границы версии, которую реально можно запустить
После такого этапа обычно исчезает до 25-30% функций, которые звучали убедительно, но не влияли на старт. В прошлом году в логистическом сервисе мы сократили первый релиз с 5 месяцев до 3,5 месяцев и сняли примерно 22% бюджета только потому, что убрали вторую цепочку согласования, конструктор отчетов и аналитику на вырост.
Хорошая оценка похожа на инженерный документ: у нее есть границы первой версии, допущения и список того, что пока не входит.
Стек должен окупаться, а не впечатлять
Я спокойно отношусь к модным архитектурам, пока они действительно нужны бизнесу. Для кабинета с документами, ролями и интеграциями чаще выигрывает прагматичный стек: Laravel 11 или Node.js 20 + NestJS, PostgreSQL 16, иногда Redis 7, если есть очереди и нагрузка. Цифры обычно говорят просто: чем больше слоев без прямой пользы для релиза, тем дороже каждое изменение.
Мы делали аудит стартапа, который начал с отдельного auth-сервиса, нескольких микросервисов и тяжелого фронтенда. На схеме все выглядело аккуратно. На практике правка одного бизнес-правила проходила через несколько репозиториев, MVP задержался на 11 недель, а поддержка выходила дороже на 15-40%, чем у более прямой архитектуры.
Интеграции я всегда считаю отдельной строкой риска. Если у внешнего API слабая документация или нестабильные методы, одна такая связка легко добавляет к смете 10-20%. Формально это выглядит как «подключить по API», но по факту здесь нужен запас на неизвестность.
Стоимость считают по сценариям, а не по экранам
Когда подрядчик оценивает приложение по числу страниц, я бы насторожился. Один экран с таблицей может стоить как пара лендингов, если внутри есть права, массовые действия, экспорт, аудит и нестандартные статусы.
На цену сильнее всего влияют не экраны, а вот что:
- число ролей и исключений в сценариях
- количество внешних систем и качество их API
- сложность модели данных и требования к безопасности
- объем QA перед запуском и цена ошибки после релиза
Если хотите получить смету, которой можно доверять, пришлите подрядчику не формулировку «нужен кабинет», а короткий набор: цель, роли, сценарии, интеграции и критерий первого запуска. Я много раз видел дорогие проекты, которые начинались с бедного брифа. Самый дешевый способ сэкономить на разработке - еще до сметы честно описать, где у вас контент, а где уже бизнес-процесс.
