Разработка MVP продукта: что это, сколько стоит и как не превратить его в полноценный продукт

MVP — минимально работающая версия продукта, которая проверяет одну бизнес-гипотезу на реальных пользователях. Простой MVP делается от двух недель, мобильное приложение или решение с бэкендом — за один-два месяца. Бюджет начинается от 250 тысяч за чат-бота и от 1,7 миллиона за мобильное приложение.

Но вот что стоит понять до старта. Вы заказываете не дешёвую версию продукта. Вы заказываете ответ на вопрос. И если в MVP не встроена аналитика, ответа вы не получите — каким бы хорошим ни вышло приложение.

Прототип, MVP, полноценный продукт: не путать

Три разных вещи, которые в переписке с подрядчиком сливаются в одну.

Главный критерий — можно ли этим пользоваться по-настоящему. Прототип показывает идею, но ничего не делает: нажал кнопку, увидел следующий экран. MVP — простой, но живой продукт, у него есть база, логика и настоящие пользователи.

А теперь то, из-за чего большинство разговоров про MVP идёт наперекосяк.

MVP — это не урезанная версия вашего продукта. Это инструмент проверки одной гипотезы. Вопрос, на который он отвечает, звучит примерно так: «будут ли люди этим пользоваться и платить».

Разница принципиальная. Если думать про MVP как про «продукт попроще», то логика такая: возьмём задуманное и уберём процентов сорок. Если думать про него как про проверку гипотезы, логика другая: что минимально нужно собрать, чтобы получить ответ.

Второй подход почти всегда даёт продукт втрое меньше и втрое быстрее.

Кому нужен MVP

Трём типам заказчиков, и задачи у них разные.

Стартапу — проверить спрос до того, как идти за деньгами. Можно полгода строить продукт и обнаружить, что он никому не нужен. А можно за полтора месяца запустить простую версию, собрать реакцию и уже с цифрами идти к инвесторам.

Действующему бизнесу — проверить новое направление без годового бюджета. У вас цветочный магазин, и вы думаете про подписку на еженедельные букеты. Делаете простого бота в телеграме. Пошли заказы — разрабатываете нормальное приложение. Не пошли — потеряли пару недель и немного денег вместо годового бюджета.

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

Теперь когда MVP не нужен:

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

Общий признак ниш, где MVP оправдан: нет уверенности, что проект окупится, а ошибка стоит дорого. Чаще всего это e-commerce и маркетплейсы, финтех, образование, телемедицина и B2B-софт с интеграциями. Финансовый риск там такой, что полтора месяца на проверку гипотезы окупаются сразу.

Сроки и бюджет

Порядки, чтобы было от чего отталкиваться.

Цифры — порядок, а не предложение: точную стоимость называем после разбора гипотезы. Получить расчёт

Относительно подхода «сделаем сразу всё» MVP экономит 35–50% бюджета. Но экономия здесь — побочный эффект, а не цель.

Главное — срок. И вот почему.

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

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

Что входит в стоимость MVP. Анализ и упаковка идеи, проектирование и дизайн, разработка короткими спринтами, настройка аналитики (счётчики, события, воронки), для мобильных — подготовка к публикации в App Store, Google Play и RuStore. Поддержка после запуска считается отдельно.

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

Главная ошибка: раздувание объёма

Механика всегда одна и та же.

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

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

Рабочее правило простое. Если фича не влияет на проверку гипотезы — она не в MVP. Не «отложим на потом, если успеем», а прямо сейчас вычёркиваем.

Проверяется так: представьте, что фичи нет. Сможете ли вы после запуска ответить на свой главный вопрос? Если да — вычёркивайте.

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

Не бюджет, не сроки, не стек. Именно здесь MVP-проекты и умирают.

Как мы держим объём. Перед стартом фиксируем документом, что входит в первую версию, и для каждой задачи описываем критерии приёмки. Идея, пришедшая в середине проекта, не теряется: она попадает в список второй очереди.

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

На чём делать MVP

Критерий выбора на этом этапе один — скорость выхода. Не масштабируемость, не архитектурная красота.

• Кроссплатформа (Flutter, React Native) — один код на iOS и Android вместо двух нативных приложений. Экономия до 40%, как минимум на первых этапах.
• Быстрые бэкенд-стеки (Go, Python) — рабочий сервис собирается в разы быстрее.
• No-code и low-code — визуальные конструкторы, если гипотезу надо проверить совсем быстро и дёшево. Скорее всего, в продакшн такое решение не подойдёт — это инструмент только для проверки.

Про no-code отдельно, потому что вокруг него много как восторгов, так и снобизма.

Он отлично работает там, где логика типовая: формы, заявки, простые каталоги, боты. Упирается в потолок там, где начинается нестандартная логика, серьёзная нагрузка или интеграции с чем-то кроме популярных сервисов. Потолок наступает быстрее, чем обещают в рекламе, но до него no-code честно экономит и время, и деньги.

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

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

Наш стек и когда мы его не рекомендуем. Для платформы с интеграциями и нагрузкой берём Go и SvelteKit: код первой версии становится основой продукта, а не одноразовой заготовкой.

Если нужно только проверить спрос, посоветуем другое: no-code, телеграм-бот или готовый конструктор. Это быстрее и дешевле, а сделать «настоящий» продукт можно после того, как гипотеза подтвердится. Для вашей задачи мы честно скажем, какой вариант подходит.

Как устроена разработка MVP

Шесть шагов. Ничего экзотического, но важно, чтобы все были.

1. Анализ и упаковка идеи. Разбираемся, что за продукт и зачем. Изучаем аудиторию и конкурентов, формулируем гипотезу. Решаем, что в первой версии, а что откладываем.

2. Проектирование и дизайн. Структура продукта: как пользователь двигается по экранам, куда нажимает, что видит. Прототипы и понятный интерфейс.

3. Итеративная разработка. Короткими спринтами: взяли кусок функционала, спроектировали, написали, протестировали. Не «полтора месяца тишины, потом показываем».

4. Публикация. Для мобильных — иконки, скриншоты, описания и модерация в App Store, Google Play и RuStore. Сроки модерации закладываются отдельно, их часто забывают.

5. Настройка аналитики. Счётчики, события, воронки. Без этого шага всё предыдущее не имеет смысла — об этом ниже отдельно.

6. Сопровождение и доработка. Обратная связь пришла, критичные ошибки правим, чего-то не хватает — добавляем.

Между запуском и массовым использованием разумно вставить ограниченный запуск: только на часть пользовательской базы или на один город. Данные соберёте, а если что-то пойдёт не так — это увидит не весь рынок.

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

MVP без аналитики бессмысленен

Финальная и самая неприятная мысль.

Продукт вашего MVP — это не приложение. Это данные. Сколько людей пришло, что они делали, где застряли, почему ушли, сколько вернулось на второй день.

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

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

Что смотреть:

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

Дальше цикл: разработка — запуск — проверка — улучшение. Гипотеза подтвердилась — добавляете функции и масштабируете. Не подтвердилась — меняете гипотезу или закрываете проект.

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

Начните с одного вопроса, на который MVP должен ответить, и вычеркните всё, что на этот ответ не влияет.

Если гипотеза очевидна и MVP не нужен — заказная разработка ПО. Если вы строите подписочный продукт — разработка SaaS-платформы. Если клиенты — юрлица с договорными ценами — B2B-платформа.