Как считают стоимость веб-сервиса и SaaS

По оценке McKinsey, крупные IT-проекты в среднем выходят за рамки бюджета почти наполовину, а каждый пятый превышает смету настолько, что ставит под угрозу сам бизнес. Для веб-сервисов и SaaS это особенно чувствительно: аналитики CB Insights называют «закончились деньги» одной из главных причин закрытия продуктовых компаний. При этом мировой рынок SaaS, по данным Statista, продолжает расти двузначными темпами — конкуренция высокая, и переплата на старте лишает продукт запаса прочности. Поэтому понимать, как формируется стоимость разработки веб-сервиса, важно не только чтобы уложиться в бюджет, но и чтобы отличить честный расчёт от заниженного «на входе».

В этой статье разберём, из чего реально складывается смета веб-сервиса и SaaS, какими методами подрядчики оценивают проект, чем отличаются модели Fixed Price и Time & Material, какие статьи бюджета делают SaaS дороже обычного сайта и во что обходится владение сервисом после запуска. В конце — практический чек-лист, как прочитать смету и проверить её на адекватность. Материал будет полезен основателям и руководителям, которые заказывают разработку и хотят принимать решения о бюджете с открытыми глазами.

Содержание

Из чего складывается стоимость веб-сервиса

Стоимость разработки веб-сервиса — это не цена «за сайт» и не количество страниц. Это сумма трудозатрат всех специалистов, которые участвуют в проекте, умноженная на их ставки, плюс расходы на инфраструктуру и сопровождение. Считать проект «на глаз», по аналогии с лендингом, — главная причина, почему реальный бюджет потом расходится с ожиданиями в разы.

Если разложить смету на составляющие, в ней почти всегда есть шесть крупных блоков:

• Аналитика и проектирование. Сбор требований, описание сценариев, техническое задание, архитектура. Обычно 10–20% бюджета, но именно этот этап определяет, не придётся ли переделывать остальное.
• UX/UI-дизайн. Прототипы экранов, пользовательские сценарии, визуальный стиль, дизайн-система. Чем больше уникальных экранов и ролей, тем дороже.
• Фронтенд. Вёрстка и логика интерфейса, который видит пользователь: личный кабинет, дашборды, формы, интерактив.
• Бэкенд. Серверная логика, база данных, бизнес-правила, права доступа, интеграции с внешними системами и платёжными шлюзами. В сложных сервисах это самая объёмная часть.
• Тестирование и приёмка. Ручное и автоматизированное тестирование, исправление дефектов, стабилизация перед релизом. Часто закладывают 15–25% от разработки.
• DevOps и запуск. Настройка серверов или облака, CI/CD, мониторинг, развёртывание в продакшн.

Ставку каждого специалиста и объём его работы подрядчик оценивает отдельно, а итог складывает. Поэтому две сметы на «похожие» сервисы могут отличаться в несколько раз: разница обычно не в жадности, а в глубине проработки требований, количестве интеграций и требуемой надёжности системы.

Как подрядчик оценивает проект: методы оценки

Оценка стоимости — это отдельная инженерная задача. Хорошая команда не называет цифру «из головы», а использует один из проверенных методов оценки, а чаще их комбинацию:

• Декомпозиция (снизу вверх). Проект разбивают на функции и задачи, для каждой оценивают трудозатраты в часах, затем суммируют. Самый точный метод, но требует детального ТЗ. Именно так считают Fixed Price-проекты.
• Экспертная оценка по аналогии (сверху вниз). Команда опирается на похожие проекты из своего опыта: «сервис такого класса обычно занимает столько-то». Быстро и полезно на старте, но точность ниже — подходит для предварительной вилки.
• Метод трёх точек (PERT). Для каждой задачи берут три оценки — оптимистичную, реалистичную и пессимистичную — и выводят взвешенное значение. Это честный способ учесть неопределённость и не занизить бюджет.
• Планирование по Story Points. В гибких командах задачи оценивают в относительных единицах сложности, а не в часах, и переводят в сроки через скорость команды (velocity). Хорошо работает для длинных продуктовых проектов.

Важный сигнал зрелости подрядчика — наличие в смете «вилки» и заложенного риска. Оценка вида «ровно 1 000 000 рублей и ни рублём больше» на старте, когда требования ещё не детализированы, чаще означает, что часть работ просто не увидели. Реалистичная оценка обычно выглядит как диапазон, который сужается по мере проработки ТЗ.

Модели ценообразования: Fixed Price, Time & Material и гибрид

От выбранной модели зависит не только цифра в договоре, но и то, кто несёт риск изменений. Три основные модели:

Модель	Как считается	Когда подходит
Fixed Price (фиксированная цена)	Полная декомпозиция по детальному ТЗ, цена и срок зафиксированы заранее	Небольшой сервис или MVP с понятными, стабильными требованиями
Time & Material (время и материалы)	Оплата по фактически затраченным часам команды по согласованным ставкам	Продукт, который развивается итерациями, требования уточняются на ходу
Гибрид / выделенная команда	Фикс на MVP-ядро плюс T&M на развитие, либо помесячная оплата команды	Долгий SaaS-проект с постоянным потоком доработок

Fixed Price кажется безопаснее — «знаю цену заранее», — но за фиксацию платят закладкой риска: команда добавляет буфер на неизвестность, а любое изменение требований оформляется как отдельный платный запрос. Time & Material гибче и прозрачнее по деньгам, но требует вовлечённости заказчика и доверия к подрядчику. Для веб-сервиса и SaaS, которые почти всегда развиваются после запуска, чаще выбирают гибрид: фиксированная оценка на первую версию и работа по спринтам дальше.

Почему SaaS дороже обычного сайта: скрытые статьи бюджета

Одна из самых частых ошибок в оценке — считать SaaS как «сайт с личным кабинетом». Веб-сервис, который клиенты используют как продукт и за который платят, содержит несколько слоёв, невидимых на первый взгляд, но заметно влияющих на бюджет:

• Мультиарендность (multi-tenancy). В SaaS одним экземпляром пользуются много клиентов, а их данные должны быть надёжно изолированы. Архитектура, которая это обеспечивает, сложнее и дороже одиночного приложения.
• Тарифы, биллинг и подписки. Расчёт тарифных планов, пробные периоды, автоматические списания, интеграция с платёжными системами и работа с неудавшимися платежами — это отдельный, довольно объёмный модуль.
• Роли и права доступа. Администраторы, менеджеры, обычные пользователи, гостевой доступ — гибкая система прав почти всегда недооценивается на старте.
• Безопасность и соответствие требованиям. Защита персональных данных, требования 152-ФЗ и хранение данных внутри страны, аудит доступа, шифрование — обязательная, а не опциональная статья.
• Масштабируемость и отказоустойчивость. Сервис, который должен работать 24/7 и держать рост нагрузки, требует продуманной инфраструктуры, резервирования и мониторинга.

Именно эти слои объясняют, почему смета на SaaS выше, чем на визитку или каталог. Если вы планируете полноценный продукт, имеет смысл сразу смотреть на разработку SaaS как на отдельную услугу с собственной архитектурой, а не как на «большой сайт».

Стоимость владения: во что обходится сервис после запуска

Цена в договоре на разработку — это только запуск. Полная стоимость владения (Total Cost of Ownership) складывается ещё и из расходов, которые начинаются после релиза и продолжаются всё время жизни продукта:

• Инфраструктура. Серверы или облако, базы данных, хранилища, CDN, домены и сертификаты — ежемесячный счёт, растущий вместе с числом пользователей.
• Поддержка и сопровождение. Исправление ошибок, обновления зависимостей и библиотек, реакция на инциденты. Ориентир — 15–20% от стоимости разработки в год.
• Развитие продукта. Новые функции, доработки по обратной связи, эксперименты. Для живого SaaS это не разовая, а постоянная статья.
• Лицензии и внешние сервисы. Платные API, системы аналитики, рассылки, мониторинг — по подписке.

Грамотный подрядчик показывает не только цену разработки, но и прогноз стоимости владения хотя бы на год вперёд. Это отличает продуктовый подход от «сдал и забыл»: дешёвый старт легко оборачивается дорогой эксплуатацией, если про инфраструктуру и поддержку вспомнили в последний момент.

Как проверить смету и не переплатить: чек-лист

Чтобы прочитать коммерческое предложение осознанно и не переплатить, пройдите смету по нескольким пунктам:

1. Проверьте детализацию: смета разбита по этапам и функциям, а не одной строкой «разработка сервиса».
2. Убедитесь, что учтены аналитика, дизайн, тестирование и DevOps, а не только «программирование».
3. Уточните, какая модель ценообразования используется и как оформляются изменения требований.
4. Спросите про стоимость владения: инфраструктуру, поддержку и развитие на год вперёд.
5. Ищите обоснование и вилку: реалистичная оценка учитывает неопределённость, а не выдаёт «точную» цифру по нечётким требованиям.
6. Сравнивайте предложения по составу работ, а не только по итоговой сумме — самая дешёвая смета часто оказывается самой неполной.

Если проходить эти шаги в одиночку сложно, разумно привлечь команду, которая покажет расчёт прозрачно. Мы в YuSMP Group оцениваем проект на этапе аналитики и обосновываем каждый блок сметы — посмотрите разработку веб-приложений, если планируете собственный веб-сервис или SaaS.

Заключение

Стоимость веб-сервиса и SaaS — это не цена «за сайт», а сумма трудозатрат всех участников проекта плюс расходы на инфраструктуру и сопровождение. Считают её через декомпозицию задач и методы оценки, учитывающие неопределённость, а выбранная модель ценообразования определяет, кто несёт риск изменений. SaaS дороже обычного сайта из-за мультиарендности, биллинга, ролей и требований к безопасности, а полная картина бюджета обязательно включает стоимость владения после запуска.

Чтобы не переплатить, читайте смету по составу работ, а не по итоговой цифре, требуйте детализации и обоснования и смотрите на горизонт в год-два, а не только на дату релиза. Прозрачный расчёт с обоснованием по каждому этапу — главный признак того, что подрядчик считает ваш проект честно.

Найдем лучшее решение для вас

Частые вопросы (FAQ)

От чего сильнее всего зависит стоимость веб-сервиса?

Главные факторы — объём и сложность функций, количество интеграций с внешними системами, требования к нагрузке и безопасности, а также число ролей пользователей. Именно они определяют трудозатраты команды. Дизайн и «красота» влияют меньше, чем архитектура и бизнес-логика: невидимая серверная часть в сложном сервисе почти всегда дороже интерфейса.

Почему разные подрядчики называют разную цену за один и тот же проект?

Чаще всего дело не в жадности, а в разной глубине проработки требований и в том, что именно включено в смету. Одна команда закладывает аналитику, тестирование, DevOps и поддержку, другая считает только «программирование». Поэтому сравнивать предложения нужно по составу работ, а не только по итоговой сумме — самая низкая цена нередко означает самую неполную смету.

Что выгоднее — Fixed Price или Time & Material?

Fixed Price удобен, когда требования стабильны и хорошо описаны: вы знаете цену заранее, но платите за фиксацию заложенным буфером риска. Time & Material выгоднее для продуктов, которые развиваются итерациями: вы платите за фактическую работу и гибко меняете приоритеты. Для SaaS часто оптимален гибрид — фикс на первую версию и работа по спринтам дальше.

Нужно ли закладывать бюджет на период после запуска?

Да, обязательно. Помимо разработки есть стоимость владения: инфраструктура, поддержка, обновления и развитие продукта. Ориентировочно на сопровождение закладывают 15–20% от стоимости разработки в год, плюс ежемесячные расходы на серверы и внешние сервисы. Сервис без бюджета на поддержку быстро устаревает и накапливает технический долг.

Можно ли узнать примерную стоимость до детального ТЗ?

Да, на старте команда обычно даёт предварительную вилку по аналогии с похожими проектами, а точную смету формирует после аналитики и декомпозиции. Это нормальная практика: чем детальнее требования, тем уже становится диапазон. Оставьте заявку — мы разберём вашу задачу, предложим архитектуру и рассчитаем прозрачную стоимость с обоснованием по этапам.