Сколько стоит и сколько длится разработка MVP: из чего складывается оценка

Разработка MVP веб-сервиса у студии обычно занимает от 8 до 16 недель, а стоимость определяется объёмом функций, а не «ценой MVP вообще». Оценка складывается из четырёх частей: аналитика и проектирование, разработка по списку функций, тестирование и запуск, запас на неизвестное. Точную цифру можно назвать только после разбора сценариев.

Разберём, из чего состоит каждая часть и как не переплатить за то, что на старте не нужно.

Почему у MVP нет фиксированной цены?

Фиксированной цены нет, потому что MVP — это не размер проекта, а подход: минимальный набор функций, который проверяет гипотезу. Для одного продукта это лендинг с формой и таблицей заявок, для другого — двусторонний маркетплейс с платежами и модерацией. Разница в объёме между ними — в десятки раз.

Поэтому вопрос «сколько стоит MVP» без описания продукта не имеет ответа. Правильный вопрос — «сколько стоят вот эти пять сценариев». Чем точнее описаны сценарии, тем уже вилка оценки: по одной фразе «нужен сервис как Авито» разброс будет в разы, а по списку экранов и ролей — в пределах запаса на неизвестное. Поэтому до сметы мы проводим короткий разбор задачи с заказчиком.

Из чего складывается оценка?

Оценка складывается из объёма работ по каждому сценарию плюс обязательные этапы, без которых продукт не запустится. Вот как мы раскладываем смету:

Часть	Что входит	Доля в оценке (ориентир студии)
Аналитика и проектирование	Сценарии, структура данных, прототипы экранов	10–15%
Дизайн интерфейса	Макеты ключевых экранов и UI-кит	10–15%
Разработка	Фронтенд, бэкенд, админка, интеграции	50–60%
Тестирование и запуск	Проверка сценариев, настройка серверов, мониторинг	10–15%
Запас на неизвестное	Уточнения, которые всплывают по ходу	10–15%

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

Как считается разработка

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

Сценарий «Оплата заказа»
  фронтенд   — корзина, выбор способа, статус оплаты
  бэкенд     — создание платежа, вебхук банка, чек
  админка    — список оплат, возврат
  проверка   — успешная оплата, отказ, повторный вебхук

Сколько длится разработка MVP?

Типичный MVP веб-сервиса студия делает за 8–16 недель от брифа до запуска. Это наша практика на проектах с командой из 3–5 человек; простой продукт уложится быстрее, сложный с интеграциями — дольше.

Сроки растягивают не столько функции, сколько ожидание решений. Неделя на согласование макетов или доступов к API банка — это неделя, в которую команда не может двигаться дальше.

Что ускоряет запуск

1. Один человек со стороны заказчика, который принимает решения.
2. Готовые доступы к внешним сервисам до начала разработки.
3. Еженедельные демо вместо приёмки в конце этапа.
4. Отказ от «приятных мелочей» до первого релиза.

Как выглядит неделя проекта

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

Такой ритм делает сроки предсказуемыми: заказчик каждую неделю видит, сколько сценариев готово и сколько осталось, и может заранее решить, что перенести во вторую версию.

Что можно не делать в первой версии?

В первой версии можно не делать всё, что не участвует в проверке гипотезы. Если продукт проверяет, готовы ли люди платить за сервис, важнее рабочая оплата, чем личный кабинет с настройками уведомлений.

Что мы чаще всего предлагаем отложить:

• мобильные приложения — адаптивная веб-версия проверяет спрос дешевле;
• сложные роли и права — на старте хватает двух-трёх ролей;
• собственную аналитику — первые месяцы закрывают готовые сервисы;
• автоматизацию редких операций — их можно делать вручную из админки.

Фиксированная цена или оплата по времени?

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

Поэтому мы обычно предлагаем гибрид:

• фиксируем аналитику и проектирование — у этого этапа понятный результат;
• оцениваем разработку по сценариям и показываем вилку, а не одну цифру;
• считаем по факту изменения, которые заказчик добавляет по ходу, — с согласованием до начала работ.

Чем опасна слишком низкая оценка

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

Как не переплатить за MVP?

Чтобы не переплатить, фиксируйте объём до старта и меняйте его осознанно. Смета с разбивкой по сценариям позволяет увидеть, за что вы платите, и убрать лишнее ещё до начала работ.

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

Коротко

• Цена MVP зависит от набора сценариев, а не от слова «MVP».
• Оценка = проектирование + дизайн + разработка + запуск + запас на неизвестное.
• Типичный срок у студии — 8–16 недель; дольше делают не функции, а ожидание решений.
• Откладывайте всё, что не проверяет гипотезу, но не экономьте на данных, авторизации и платежах.