К содержимому
MVP и продукт

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

Почему оценки на один и тот же MVP отличаются в пять раз, что реально влияет на стоимость и как не переплатить за то, что не проверяет гипотезу.

4 минуты чтения
Содержание статьи
  1. Что вы покупаете, когда покупаете MVP
  2. Пять множителей, которые двигают цену
  3. Ориентиры, а не прайс
  4. Как срезать бюджет, ничего не потеряв
  5. Красные флаги в оценке
  6. Другая модель: доля вместо счёта

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

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

Что вы покупаете, когда покупаете MVP

Цена почти никогда не состоит из «написать экраны». В любой честной оценке есть четыре части.

Продуктовая работа. Превратить «сервис для мебельщиков» в список конкретных сценариев. Это 10–20% бюджета, и это единственная часть, экономия на которой гарантированно удорожает остальное.

Разработка. Собственно код: интерфейс, серверная логика, база, интеграции.

Инфраструктура и запуск. Хостинг, домены, платежи, почта, сбор ошибок, резервные копии. Мелочи, которые в сумме дают недели.

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

Оценка, где есть только вторая часть, — это не оценка MVP, а оценка написания кода по вашему эскизу. Разница проявится ровно в тот момент, когда придут первые пользователи.

Пять множителей, которые двигают цену

1. Количество ролей. Продукт для одного типа пользователя и продукт, где есть клиент, исполнитель и администратор, — это разница не в полтора раза, а в три. Каждая роль — свои экраны, свои права, свои состояния.

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

3. Интеграции с чужими системами. Особенно с теми, где нет нормальной документации или где доступ выдают неделями. Самый частый источник срыва сроков.

4. Мобильное приложение. Если можно обойтись адаптивным сайтом — обойдитесь. Публикация в сторах, ревью, две платформы и обновления добавляют к бюджету десятки процентов и недели ожидания.

5. Требования к данным. Персональные данные, медицина, финансы — это отдельные требования к хранению и доступу. Их нельзя «добавить потом».

Ориентиры, а не прайс

Честный диапазон сильно зависит от рынка и команды, но порядок величин выглядит так.

  • Ручной режим и готовые кубики — от нескольких десятков тысяч рублей и недели работы. Часто этого достаточно, чтобы проверить спрос. Подробнее — в статье про no-code и код.
  • Один сценарий, одна роль, без платежей — 1,5–2 месяца работы небольшой команды.
  • Две-три роли, платежи, одна-две интеграции — 3–4 месяца.
  • Всё вышеперечисленное плюс мобильное приложение и требования к данным — от полугода, и это уже не MVP.

Если вам называют срок «две недели под ключ» на третий пункт — это не скорость, а недооценка, которая всплывёт в середине проекта.

Как срезать бюджет, ничего не потеряв

Уберите всё, что не проверяет гипотезу. Личный кабинет с настройками, экспорт в PDF, уведомления по трём каналам, тёмная тема — всё это можно добавить, когда станет ясно, что продукт нужен. Критерий один: без какой функции нельзя получить ответ на главный вопрос?

Замените автоматизацию человеком. Модерация, подбор, расчёт — на первых десятках клиентов всё это дешевле делать руками. И полезнее: вы увидите реальные крайние случаи.

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

Откажитесь от собственной авторизации. Вход по почте или через готового провайдера закрывает вопрос на месяцы вперёд.

Ограничьте сегмент. Продукт для одной ниши в одном городе дешевле продукта «для всех» именно потому, что в нём меньше исключений.

Красные флаги в оценке

  • Оценка без вопросов. Если у подрядчика не возникло десяти уточнений — он посчитал не вашу задачу.
  • Фиксированная цена на неопределённое ТЗ. Риск заложен в цену, и заложен щедро.
  • Отдельная строка «дизайн» размером с разработку — на MVP это почти всегда лишнее.
  • Нет строки на запуск и первый месяц после него.
  • Сроки в неделях при списке функций на страницу.

Другая модель: доля вместо счёта

Есть вариант, при котором вопрос «сколько стоит MVP» звучит иначе. Мы в IDEA-AI не берём деньги за разработку — мы входим в проект долей. Это меняет не только платёж, но и мотивацию: подрядчику выгодно сделать больше функций, партнёру — быстрее найти работающую гипотезу и не потратить месяцы впустую.

Такая модель подходит не всем и не всегда: она требует совпадения по фаундеру, рынку и готовности делить компанию. Про то, как это устроено, — в статьях про условия и деление долей.

Но независимо от модели правило одно: самый дорогой MVP — тот, который отвечает на вопрос, который вы не задавали. Сначала вопрос, потом смета.

Применить это к своему проекту

Вы знаете отрасль — мы собираем продукт. За долю, а не за чек. Расскажите про свою идею, разберём её вместе.

Оставить заявку