В прошлом году к нам пришел производитель оборудования с вопросом: почему в одном КП сайт стоит 680 тыс. ₽, а в другом 1,9 млн ₽, если по картинкам все почти одинаково. Мы за час разобрали сметы и увидели простую вещь: в дешевой не было аналитики, QA, нормального описания интеграции с amoCRM, а личный кабинет вообще был заявлен одной строкой, без ролей и статусов.
Самый дорогой сайт в моей практике на старте стоил 700 тыс. ₽. Его купили как "почти готовый", потом 6 месяцев чинили, переносили и дописывали, потому что реальный бизнес оказался сильно сложнее первого брифа. Короче, цена почти всегда сидит не в макете, а в том, что должно происходить после клика и после релиза.
Снаружи один сайт, внутри - разный объем работы
Первое, что двигает смету, - тип проекта. Лендинг, корпоративный сайт, каталог, магазин, кабинет партнера, сервис для клиентов - это разные классы задач, даже если главная страница выглядит похоже.
У нас был B2B-проект в дистрибуции. Клиент пришел с формулировкой "нужен сайт услуг, как у конкурента". После интервью картина стала другой: 3 роли, 17 статусов, согласование заявок, история заказов, мультиязычность и обмен с CRM. Визуально - аккуратный корпоративный сайт. По трудозатратам - почти внутренний рабочий инструмент.
Следующий фактор - архитектура и роли. Публичная часть может быть простой, но внутри часто живут админка, права доступа, уведомления, журнал действий. Еще один важный момент - нестандартные блоки. 10 типовых страниц на WordPress 6.6 делаются быстрее, чем 3 страницы с калькулятором, фильтрами и логикой под разные сценарии.
"Заказчики сравнивают главную страницу, а платить потом приходится за бизнес-логику", - CTO логистической платформы.
Бюджет разгоняют сценарии, а не красота макета
Самые дорогие куски проекта - пользовательские сценарии. Регистрация, оформление заказа, возврат, повторная покупка, согласование, уведомления в почту и мессенджеры. Каждый такой путь надо придумать, собрать, проверить и потом поддерживать.
Если скидка зависит от региона, типа клиента, остатков и истории заказов, это уже отдельный слой разработки. То же самое с интеграциями: CRM, ERP, 1С, платежи, доставка, телефония, склад. Здесь дорожает не только бэкенд, но и QA, потому что нужно прогнать ошибки, повторы, задержки и частичные сбои.
Когда на сайт заходят 50 человек в день, подходит одна архитектура. Когда в пике приходит 10 000 посетителей и параллельно работает кабинет партнеров, уже нужны кеширование, очереди и нормальный мониторинг. Мы обычно собираем такие вещи на Laravel 11 или Node.js 20 + NestJS, база - PostgreSQL 16, кеш и очереди - Redis. Но стек тут вторичен. Если сценарии не описаны, ошибиться в смете можно на любом фреймворке.
| Вариант | Что внутри | Относительная цена |
|---|---|---|
| Базовый магазин | каталог, корзина, заказ | 1X |
| Магазин с CRM и складом | остатки, статусы, обмен данными | 1.4X–1.8X |
| Магазин с акциями и возвратами | бонусы, правила скидок, возвраты | 1.8X–2.3X |
| Проект с кабинетами | роли, история, уведомления | 2.5X+ |
Самые дорогие решения принимаются до первой строки кода
Девятый фактор - качество брифа. Десятый - discovery, то есть предпроектная аналитика. Одиннадцатый - изменения объема работ по ходу проекта. Вот эти три пункта чаще всего и превращают "дешевую" смету в дорогую.
Я бы сделал так: до старта зафиксировал роли, ключевые сценарии, интеграции, границы MVP и то, что уходит на второй этап. У нас discovery обычно занимает 1-2 недели и стоит 5-15% бюджета, но потом экономит 1-2 месяца переделок.
Небольшой срез по одному проекту в услугах:
- До discovery - смета 820 тыс. ₽, срок 8 недель
- После discovery - смета 1,14 млн ₽, срок 11 недель
- Что нашли - кабинет менеджера, 300 SEO-страниц, 2 воронки, интеграция с Bitrix24
- Что сэкономили - не переделывали архитектуру перед релизом
Мы сами на этом обжигались. Один раз зашли в проект слишком рано, по короткому описанию. Через месяц всплыл новый статус заказа, а за ним потянулись права доступа, уведомления, фильтры, отчеты и тесты. Снаружи правка выглядела небольшой, а по факту срок уехал на 3 недели. С тех пор в код раньше времени не идем.
Тип проекта:
Роли пользователей:
Ключевые сценарии:
Интеграции:
Что обязательно в MVP:
Что уходит на 2 этап:
Дешевый старт иногда разумен. Иногда это просто отложенная миграция
Для лендинга, простого корпоративного сайта или каталога Tilda, WordPress, WooCommerce, Shopify, 1C-Битрикс - нормальный выбор. Если задача запуститься за 4-6 недель и быстро проверить спрос, я сам часто иду туда.
Проблемы начинаются, когда на простой базе пытаются строить сервис с ролями, API и сложными статусами. У нас был B2B-стартап, который купил сайт на конструкторе: каталог, форма заявки, кабинет "потом". Через 6 месяцев понадобились роли, API, статусы заказов и интеграция с amoCRM. Платформа уже не тянула. Бюджет на доработки почти догнал новую разработку на Node.js 20 + NestJS.
Здесь появляется двенадцатый фактор - стоимость владения после релиза. Лицензии, ограничения платформы, цена доработок, скорость работы, стоимость поддержки - это реальные деньги, которых часто нет в первом КП.
Смотрите на состав сметы, а не на одну цифру
Если подрядчик пишет "создать сайт - 600 тыс. ₽", это еще не цена проекта. Это может быть только дизайн, верстка и базовый бэкенд без QA, миграции контента, SEO-подготовки и поддержки после запуска.
Я бы просил смету по блокам:
- аналитика и проектирование
- дизайн, фронтенд, бэкенд, интеграции
- QA, контент, запуск
- что входит в цену, а что идет допработами
За ближайшие 3 дня можно сильно улучшить точность оценки: собрать роли пользователей, выписать 10 ключевых сценариев, перечислить все интеграции и отправить это 2-3 подрядчикам. А потом задать один вопрос: что сломается в этой смете, когда бизнес начнет работать по-настоящему? По ответу обычно сразу видно, кто считал проект, а кто просто продал красивую цифру.
