Сколько стоит разработка веб-приложения и почему смету дают по этапам

Почему нельзя назвать цену сразу

Веб-сервис - это не типовой продукт. Даже если два заказчика просят «платформу для записи на услуги», один может иметь в виду календарь с формой, а второй - систему с ролями, интеграцией с CRM, онлайн-оплатой и уведомлениями в Telegram. Разница в цене между ними - в десять раз.

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

На сайте EFIMOV DEV опубликованы вилки «от» по услугам: лендинг, корпоративный сайт, интернет-магазин, веб-сервис. Это ориентир для бюджета, но точная смета появляется только после брифа, когда понятен масштаб задачи.

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

Разработка веб-приложения оплачивается по времени работы команды. Это не материальный товар, где есть себестоимость заготовки - это интеллектуальная работа, и её объём зависит от сложности задачи.

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

На цену влияет количество ролей пользователей. Сервис для одной роли (например, клиент записывается на услугу) стоит в два-три раза дешевле, чем система с администратором, менеджером и клиентом, у каждого из которых свой интерфейс и права.

Интеграции добавляют стоимость непредсказуемо. Подключить оплату через готовую библиотеку - несколько часов. Связать сервис с CRM, у которой кривое API и нет документации, - несколько дней проб и костылей.

Почему смета делится на этапы

Этапная смета защищает обе стороны. Заказчик видит, за что платит, и может остановиться после любого блока, если бюджет кончился или задача изменилась. Студия не работает в минус, если проект замораживается на середине.

Типичное разделение: проектирование и дизайн, вёрстка, программирование основных функций, программирование дополнительных модулей, тестирование и правки, запуск. Каждый этап оценивается отдельно, и его можно принять независимо от следующего.

Это не значит, что можно взять дизайн в одной студии, а разработку заказать в другой. Этапы связаны логически: программист должен понимать, как устроен интерфейс, а дизайнер - что технически реализуемо. Но если на этапе вёрстки стало ясно, что бюджет не тянет полный функционал, можно урезать следующие блоки и запустить MVP.

Как не переплатить за ненужное

Заказчики часто просят функции, которыми никто не будет пользоваться. Личный кабинет с настройками, если клиент заходит один раз. Экспорт в Excel, если отчёты никто не смотрит. Система уведомлений в трёх каналах, когда достаточно email.

Нормальная студия спросит: а зачем это нужно? Если ответа нет или он звучит как «ну вдруг пригодится», функцию стоит отложить. Её можно добавить потом, когда станет ясно, что она реально нужна.

Ещё одна ловушка - делать сразу под все платформы. Веб-версия, iOS, Android - это утроение бюджета. Если бизнес только запускается, начните с веба. Если через полгода окажется, что 70% пользователей заходят с телефона, тогда сделаете приложение. Не надо строить то, использование чего вы не проверили.

Что должно быть в смете

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

В нормальной смете каждый блок расписан: «Регистрация и авторизация пользователя: форма регистрации, подтверждение email, восстановление пароля, вход через соцсети - 40 часов». Вы видите, что именно будет сделано, и можете сказать: «Вход через соцсети пока не нужен, уберите».

Смета должна включать тестирование и правки. Если их нет, они всплывут допами после сдачи проекта, и итоговая сумма вырастет на 20-30%. Правки после первого показа интерфейса - это нормальная часть работы, и они должны быть заложены в бюджет.

Почему итоговая цена может измениться

Смета фиксирует объём работ, который известен на старте. Но в процессе всплывают детали, которые никто не учёл. Например, оказывается, что у API внешнего сервиса есть лимиты, и нужно делать очередь запросов. Или что база данных заказчика устроена не так, как он описывал, и интеграция требует переделки.

Если изменения связаны с ошибкой студии или с тем, что что-то не учли на этапе брифа, это должно делаться за счёт исполнителя. Если заказчик в процессе меняет требования («а давайте тут ещё добавим фильтры»), это оплачивается дополнительно.

Хорошая практика - закладывать в смету резерв 10-15% на непредвиденное. Это не наценка, это подушка безопасности, которая позволяет не останавливать проект из-за мелких доработок.

Сколько стоит поддержка после запуска

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

Поддержку можно оплачивать по факту (каждая правка оценивается отдельно) или абонементом (фиксированная сумма в месяц за определённое количество часов). Абонемент удобнее, если правки регулярные: не нужно каждый раз согласовывать смету, студия держит проект в контексте.

На сайте EFIMOV DEV есть услуга технической поддержки - стоит уточнить условия после запуска проекта, если планируете развивать сервис дальше.

Как проверить адекватность сметы

Попросите разбить смету по блокам и покажите её знакомому разработчику или технически грамотному человеку. Он не оценит точную стоимость, но увидит, если там заложены лишние вещи или наоборот не хватает критичных этапов.

Сравните сметы от двух-трёх студий. Если одна из них в два раза дешевле остальных, это не удача - это либо недооценка (потом всплывут допы), либо низкое качество. Если одна в два раза дороже, спросите, что в неё входит сверх стандарта.

Обратите внимание на сроки. Если обещают сложный веб-сервис за месяц, это повод насторожиться. Нормальная скорость разработки - 30-40 часов программирования в неделю на одного человека, и это без учёта проектирования, дизайна, тестирования. Реалистичный срок для сервиса средней сложности - от двух до четырёх месяцев.

Если задача уже на столе - вот как мы делаем это под ключ: Разработка веб-приложений, веб-сервисов и SaaS.

Частые вопросы