Сколько стоит разработка веб-платформы: из чего складывается бюджет и как его оценить

Из чего складывается стоимость разработки веб-платформы: команда и трудозатраты, масштаб MVP, продукта и платформы, что удорожает и удешевляет проект, как пользоваться предварительной оценкой и читать смету подрядчика.

«Сколько это стоит?» — первый вопрос на любой встрече о разработке, и самый неудобный для обеих сторон. Заказчику нужен ориентир, чтобы понять, стоит ли вообще начинать разговор. Подрядчику до разбора задачи честно назвать точную сумму невозможно. В итоге одни называют «от 100 тысяч» и потом удивляют сметой, другие уходят от ответа, а заказчик получает три предложения на одну задачу с разницей в разы и не понимает, какое из них адекватное. Эта статья не даёт волшебной таблицы цен — её не существует. Зато она объясняет, из чего складывается бюджет веб-платформы, почему он так сильно зависит от масштаба, что удорожает и удешевляет проект, как быстро получить обоснованный ориентир и как читать смету подрядчика так, чтобы сравнивать предложения по существу, а не по итоговой цифре. Сайт и платформа — разные продукты Половина недоразумений о стоимости начинается с того, что стороны называют одним словом разные вещи. Сайт или лендинг — страницы с информацией о компании, услугах и продуктах, формы заявок, управление контентом. Логики немного, ролей пользователей обычно две: посетитель и редактор. Веб-сервис или платформа — система, в которой пользователи работают: личные кабинеты, несколько ролей с разными правами, бизнес-логика, платежи, интеграции с учётными системами, отчёты, требования к нагрузке и доступности. Разница в трудоёмкости между ними — не проценты, а кратные величины. На странице разработки веб-проектов стартовая цена указана для сайтов и простых веб-проектов. Платформа с личными кабинетами, ролями и интеграциями начинается с того же фундамента, но её объём определяется требованиями, и оценивать её «по цене сайта» — прямой путь к разочарованию обеих сторон. Из чего складывается бюджет В разработке почти нет материальных затрат. Стоимость проекта — это время специалистов, умноженное на их ставку, плюс инфраструктура и сторонние сервисы. Поэтому смета — ответ на вопрос «сколько времени каких специалистов нужно, чтобы сделать именно этот объём». Кто работает над продуктом Аналитик или продакт-менеджер превращает задачу бизнеса в требования, сценарии и приоритеты. Экономия на этой роли оборачивается переделками на приёмке, когда выясняется, что построено не совсем то. Дизайнер проектирует интерфейс и дизайн-систему. На платформе с десятками экранов дизайн-система обязательна, иначе каждый новый экран рисуется с нуля и выглядит по-своему. Фронтенд- и бэкенд-разработчики — основная часть трудозатрат: интерфейс, серверная логика, база данных, интеграции. Тестировщик проверяет, что продукт работает во всех сценариях, включая ошибочные. Проект без выделенного тестирования дешевле на старте и дороже в эксплуатации. DevOps-инженер отвечает за инфраструктуру, выкладку, мониторинг и резервное копирование. На первой версии роль может быть частичной, на нагруженной платформе — отдельной. Руководитель проекта планирует, координирует, согласовывает изменения и держит сроки. Как это превращается в цифру Требования раскладываются на задачи, каждая задача оценивается специалистами соответствующего профиля, к разработке добавляются тестирование, управление, инфраструктура и резерв на риски. Итог — сумма часов по ролям, умноженная на ставки. Подробнее этот путь от требований к смете мы разбирали в статье о техническом задании . Отсюда главный практический вывод: при одинаковых ставках разница в сметах почти всегда означает разницу в понимании объёма. Два подрядчика оценивают не одну и ту же работу, а две разные интерпретации вашей задачи. Что входит в бюджет, кроме разработки серверы и облачная инфраструктура на время разработки и после запуска; лицензии и подписки на сторонние сервисы: платёжные провайдеры, рассылки, карты, распознавание, языковые модели; подготовка контента, если его делает подрядчик; юридическая подготовка: оферта, политика обработки персональных данных, согласия; поддержка и развитие после запуска. Масштаб: главный множитель стоимости Одна и та же задача — например, «личный кабинет для клиентов» — может означать продукты очень разного размера. Удобно различать три уровня. MVP или пилот Минимальная версия для проверки главной гипотезы: один сквозной сценарий, одна-две роли, готовые компоненты вместо уникального дизайна, ручные процессы там, где автоматизация пока не нужна. Цель — ответить на вопрос «будут ли этим пользоваться», а не построить окончательный продукт. Как определить границы такой версии, — в статье о границах MVP . Полноценный продукт Рабочая версия для реальных пользователей: несколько ролей, административная часть, платежи, интеграция с CRM, собственный дизайн, аналитика. Самый частый запрос и самый частый источник недооценки: бюджет считают по MVP, а требования описывают продуктовые. Платформа Много ролей и сложные права доступа, интеграции с несколькими внешними системами, требования к нагрузке, отказоустойчивости и безопасности, развитая административная часть и отчётность. На этом уровне бюджет перестаёт быть разовым: платформа живёт годами, и её развитие планируется так же, как первоначальная разработка. Как получить ориентир за минуту На странице «Сколько это стоит» работает калькулятор предварительной оценки. Он устроен прозрачно: берёт стартовую цену выбранной услуги — ту же, что указана на её странице, — умножает на коэффициент масштаба и добавляет надбавки за опции. В калькуляторе полноценный продукт оценивается в 2,2 раза дороже MVP, платформа — в 4 раза; дизайн с нуля добавляет 25%, интеграции с внешними системами — 20%, AI-функции — 30%, поддержка в первые три месяца после запуска — 15%. Результат показывается вилкой, верхняя граница которой в полтора раза выше нижней. Это именно предварительная оценка, а не смета. Она помогает понять порядок бюджета до разговора. Точная стоимость платформы определяется после разбора требований: объём интеграций, нагрузка и сложность бизнес-логики могут изменить её существенно. Что удорожает проект сильнее всего Интеграции с закрытыми системами Подключение платёжного провайдера по хорошей документации — предсказуемая задача. Подключение учётной системы без документированного API, через выгрузки файлов или прямой доступ к базе — непредсказуемая. Такие узлы стоит просить оценивать отдельными строками, с явным описанием допущений. Как интеграции устроены изнутри и где они ломаются, — в статье об интеграции CRM и 1С . Требования к нагрузке и доступности «Тысяча пользователей в день» и «тысяча пользователей одновременно» — разная архитектура, разная инфраструктура и разный бюджет. Требование работать без плановых остановок меняет процессы выкладки и стоимость эксплуатации. Уникальный дизайн Оправдан, когда интерфейс — часть продукта и конкурентного преимущества: клиентский сервис, потребительское приложение. Избыточен для внутренней административной панели, где готовые компоненты справятся не хуже. Безопасность и регуляторные требования Персональные данные, платежи, медицинская или финансовая информация добавляют требования к архитектуре, хранению данных, журналированию и проверкам. Их стоит учитывать с первого дня: добавленные после запуска, они обходятся значительно дороже. Размытые требования Чем больше в описании задачи «и так далее» и «при необходимости», тем шире вилка и тем выше резерв на риски. Неопределённость не исчезает — она либо закладывается в цену, либо всплывает в виде дополнительных счетов. Отсутствие решающего лица Самая дорогая строка, которой нет ни в одной смете. Если каждое решение согласуется комитетом, сроки растут, а с ними и бюджет: команда ждёт, переделывает, ждёт снова. Что удешевляет проект без потери качества Готовые компоненты. Авторизация, платежи, уведомления, поиск, административные панели давно решены. Писать своё стоит только там, где это создаёт конкурентное преимущество. Поэтапный запуск. Вторая и третья роль пользователей, расширенные отчёты и дополнительные интеграции часто нужны через полгода, а не в день запуска. Честный отказ от функций. Значительная часть требований первичного описания после запуска не используется. Разбор задачи до старта окупается кратно. Ручные процессы на старте. Модерация, выставление счетов, часть уведомлений могут на первых порах выполняться сотрудником, пока объём операций небольшой. Быстрые прототипы. Для проверки гипотез за дни, а не месяцы, подходит вайбкод-разработка : быстрая сборка работающего прототипа с помощью AI-инструментов под инженерным контролем. Один ответственный с правом решения со стороны заказчика. Когда платформа не нужна вовсе Не всякая задача требует отдельного продукта. Если цель звучит как «убрать ручную работу на конкретном участке», часто достаточно настроить и связать уже существующие системы. Для таких задач есть автоматизация бизнес-процессов , а для внедрения языковых моделей в текущие процессы — AI-разработка ; стартовые цены указаны на страницах услуг. Разбор задачи иногда заканчивается выводом, что правильный ответ — не разработка, а настройка готовой системы, и это экономит больше, чем любая оптимизация сметы. Как читать смету подрядчика Хорошая смета отвечает на три вопроса: что входит, что не входит и что происходит при изменении требований. Признаки качественной сметы работы разбиты на этапы и функциональные блоки, а не записаны одной строкой; для каждого блока указаны роли и трудозатраты; тестирование, управление проектом и инфраструктура выделены явно; перечислены допущения — например, «интеграция по документированному API»; есть раздел «не входит в стоимость»; описан порядок оценки и согласования изменений; указаны условия гарантийного периода и поддержки. Поводы насторожиться одна строка «разработка платформы» и итоговая сумма; нет тестирования и приёмки; нет вопросов к задаче перед оценкой; фиксированная цена при размытых требованиях; цена заметно ниже остальных предложений без объяснения за счёт чего — почти всегда часть работ будет вынесена в дополнительные счета или в качество. Как сравнивать предложения Сведите предложения в таблицу по функциональным блокам, а не по итоговым суммам. Отметьте, что каждый подрядчик включил и что исключил. Часто самое дорогое предложение оказывается единственным, где заложены тестирование, аналитика и перенос данных, а самое дешёвое — единственным, где их нет. Какие вопросы задать подрядчику до подписания договора, — в статье о выборе подрядчика . Модели оплаты Фиксированная цена подходит, когда объём детально описан и стабилен. Риск изменений закладывается в цену, а любое изменение оформляется отдельно. Оплата по времени и материалам подходит новым продуктам, где требования уточняются по ходу. Заказчик платит за фактически затраченное время и управляет приоритетами. Гибрид — аналитика и проектирование по времени, разработка согласованного объёма фиксом, дальнейшее развитие по времени. На практике часто самый честный вариант для платформ. Поэтапная оплата с приёмкой результата каждого этапа защищает обе стороны независимо от модели. Частые вопросы Можно ли назвать точную цену без брифа? Нет. Можно назвать порядок бюджета по типу и масштабу проекта — для этого и существует предварительная оценка. Точная смета появляется после разбора требований. Почему разные подрядчики называют суммы, отличающиеся в разы? Чаще всего потому, что оценивают разный объём: одни закладывают аналитику, тестирование, инфраструктуру и перенос данных, другие — только написание кода. Сравнивайте состав работ, а не итоговую цифру. Сколько закладывать на поддержку после запуска? Зависит от сложности продукта, требований к доступности и планов развития. Поддержка — это мониторинг, обновления, исправление ошибок и резервное копирование; развитие — новые функции. Их стоит планировать и оценивать отдельно. Подробно — в статье о поддержке сайта и SLA . Что дешевле: своя команда или подрядчик? На горизонте первой версии подрядчик обычно выгоднее: не нужно нанимать, обучать и удерживать специалистов разных профилей. Собственная команда оправдана, когда продукт становится основным бизнесом и требует постоянного развития. Частый путь — подрядчик на старте и постепенная передача продукта внутренней коман