MVP: какой тип нужен, сколько стоит и как посчитать окупаемость
«MVP» слишком часто путают либо с кликабельным макетом в Figma, либо с урезанной версией полноценного продукта. На самом деле выбор типа MVP — это выбор, какую именно гипотезу вы проверяете и сколько готовы за это заплатить. Разбираем четыре типа, что каждый из них реально показывает, и как прикинуть, окупается ли гипотеза до того, как в неё вложены серьёзные деньги.
Разработать MVP на заказ можно за недели, а не месяцы — если правильно выбрать тип и не переплатить за лишний функционал.
Четыре типа MVP
| Тип | Что проверяет | Насколько это реальный продукт |
|---|---|---|
| Concierge / «Волшебник страны Оз» | Готовы ли люди вообще платить за решение проблемы | Процесс делается вручную за кулисами, разработки почти нет |
| Лендинг с формой предзаказа | Есть ли спрос до того, как продукт вообще существует | Нет продукта — только страница и сбор заявок |
| Однофункциональный MVP | Работает ли ключевой сценарий в реальном использовании | Рабочий продукт с реальным бэкендом, но одна функция |
| Полноценный MVP | Готов ли продукт к первому широкому запуску | Несколько функций, готов к реальным пользователям на постоянной основе |
Мы обычно рекомендуем начинать с однофункционального MVP: он даёт честный сигнал, потому что люди реально им пользуются, а не просто кликают по макету или оставляют email — и при этом не требует вложений, сопоставимых с полноценным продуктом.
Как оценить окупаемость гипотезы
Настоящая ценность MVP — не в том, что он приносит прибыль сам по себе, а в том, что он дёшево отвечает на вопрос, стоит ли вкладываться в полноценный продукт. Простая рамка для оценки:
- Стоимость MVP — понятная фиксированная сумма за разработку и первый месяц эксплуатации.
- Стоимость ошибки без MVP — сколько стоило бы обнаружить, что гипотеза не работает, уже после того, как в полноценный продукт вложены месяцы разработки и бюджет маркетинга.
- Сигнал, который дал MVP — конверсия из интереса в реальное использование, готовность платить, повторное использование продукта — конкретные и измеримые вещи, а не общее ощущение «вроде людям нравится».
Если стоимость MVP в разы меньше, чем стоимость ошибки, которую он способен предотвратить — а на практике это почти всегда так, — то отказ от проверки гипотезы через MVP обычно дороже, чем сама проверка, даже если результат окажется отрицательным.
Как выбрать подрядчика
Разработчика для такой задачи стоит выбирать по конкретным признакам, а не по общему впечатлению от презентации:
- Уточняет, что именно вы хотите проверить, прежде чем предлагать конкретный тип MVP — иначе можно получить дорогой MVP там, где хватило бы простого лендинга, или наоборот.
- Строит MVP так, чтобы его можно было развить в полноценный продукт, если гипотеза подтвердится, а не переписывать всё с нуля.
- Закрепляет права на код и данные в договоре до старта — они должны оставаться у вас независимо от результата гипотезы.
- Не предлагает сразу делать полноценный продукт, если задача — именно проверить гипотезу с минимальным риском.
Частые вопросы
Чем MVP отличается от прототипа?
Прототип — это кликабельный макет, который показывает, как продукт должен выглядеть, но не работает по-настоящему. MVP — это рабочий продукт с реальным бэкендом, которым можно фактически пользоваться, пусть и с ограниченным набором функций. Прототип проверяет, понятен ли интерфейс; MVP проверяет, готовы ли люди реально этим пользоваться и платить за это.
Нужно ли делать MVP, если продукт уже точно будут покупать?
Если спрос уже подтверждён — например, есть предзаказы или подписанные письма о намерениях от клиентов — часть риска, которую обычно снимает MVP, уже снята. В этом случае может быть разумнее сразу делать более полную версию первого релиза, а не искусственно урезать его до минимального MVP.
Можно ли MVP сразу превратить в полноценный продукт, а не переписывать заново?
Да, если MVP изначально строился как часть полноценной архитектуры, а не как одноразовый эксперимент на скорую руку. Это стоит обсуждать с подрядчиком на старте: планируется ли MVP как основа будущего продукта или как быстрый одноразовый тест, который потом осознанно выбрасывается.
Что делать, если MVP показал, что гипотеза не подтвердилась?
Это тоже полезный результат MVP, а не провал — задача MVP в том числе в том, чтобы дёшево и быстро отсеять гипотезы, которые не работают, прежде чем в них вложены полноценные бюджеты. Код и данные при этом должны оставаться у вас — договор об этом стоит закрывать до начала работ.
Сколько времени занимает разработка MVP?
Однофункциональный MVP с реальным бэкендом — не кликабельный макет — обычно занимает 2–3 недели с момента старта работ до готового пилота, которым можно дать пользоваться реальным людям.
Расскажите, какую гипотезу нужно проверить — на созвоне за 40 минут поймём, какой тип MVP даст честный ответ быстрее и дешевле всего.
Обсудить проект