Чем MVP отличается от прототипа: разбор на пальцах с примерами

«Сделайте нам прототип» — говорит один клиент. «Нам нужен MVP» — говорит второй. И мы каждый раз задаём один и тот же вопрос: а вы точно понимаете, чем одно отличается от другого?

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

Короткое определение

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

MVP (Minimum Viable Product) — это рабочий продукт с минимальным функционалом, который отвечает на вопрос: «готов ли рынок за это платить?»

Разница на одном предложении: прототип проверяет UX, MVP проверяет бизнес-модель.

Сравнительная таблица

Когда нужен прототип

Прототип нужен, если у вас одна из трёх ситуаций:

1. Продукт сложный и спорный по UX. Например, вы делаете нестандартный интерфейс — игровой кабинет с интерактивным AR, приложение для врачей с нестандартной диаграммой, банковскую CRM с десятью одновременно открытыми панелями. Прежде чем тратить миллион на разработку, нужно убедиться, что пользователи поймут логику.

2. Нужно показать инвестору, что «у нас есть продукт». Не для запуска, а для демонстрации. Кликабельный прототип в Figma — стандарт индустрии для pre-seed раундов. Никто не ждёт боевого MVP до того, как вы получите первые деньги.

3. Внутри команды нет согласия по UX. Когда один основатель видит «как у Notion», второй — «как у Airtable», третий — «как у нашей старой CRM», прототип за неделю экономит месяц споров. Вы фиксируете решение в кликах, а не в словах.

Что прототип НЕ закроет:

• Нагрузочные тесты.
• Реальные платежи.
• Интеграции с 1С, телефонией, Telegram.
• Продажи и онбординг живых клиентов.

Если хочется хоть что-то из перечисленного — вам нужен MVP.

Когда нужен MVP

MVP нужен, если у вас одна из четырёх ситуаций:

1. Вы хотите начать продавать. Это главный критерий. Если на выходе должен быть платящий клиент — это MVP, а не прототип. Точка.

2. Бизнес-модель требует проверки в реальных деньгах. «Будут ли люди покупать за 990 ₽ в месяц?» — на этот вопрос не ответит ни одна фокус-группа и ни один прототип. Только реальный продукт, в который можно ввести карту.

3. Нужны метрики для следующего раунда инвестиций. LTV, CAC, retention — это всё измеряется только в боевом продукте. На прототипе таких цифр нет.

4. У вас уже есть запрос от рынка и клиенты ждут. В этом случае каждая неделя без рабочего продукта — это упущенная выручка. Вам не нужен прототип, нужен MVP за 4–6 недель.

Главная ошибка: «сделайте нам прототип, а потом превратим его в MVP»

В 95% случаев это не работает. Объясню почему.

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

Так что на практике прототип не экономит время разработки MVP. Он экономит время проектирования — потому что UX-решения уже зафиксированы.

Правильная формула: 1. Прототип — для проверки UX и согласования с командой/инвестором. 2. MVP — для проверки бизнес-модели и старта продаж.

Не «прототип, который потом станет MVP». Это два разных инструмента под две разные задачи.

Реальный кейс из нашей практики

К нам пришёл клиент — основатель сервиса доставки еды для офисов. Бюджет 800 000 ₽, срок 2 месяца. Запрос: «сделать MVP».

Мы провели 30-минутный созвон и поняли, что у клиента две гипотезы, которые он смешивает:

1. «Понятен ли офис-менеджеру наш интерфейс заказа на 50 человек одновременно?» — это UX-гипотеза, проверяется прототипом.
2. «Готовы ли компании платить за корпоративную подписку 50 000 ₽ в месяц?» — это бизнес-гипотеза, проверяется MVP.

Мы предложили двухэтапный план:

• Этап 1, 2 недели, 120 000 ₽: интерактивный прототип в Figma. Тест с 5 потенциальными клиентами.
• Этап 2, 5 недель, 580 000 ₽: MVP с реальными заказами и подпиской — но уже с UX, который реально проверен на этих 5 клиентах.

Что получилось:

• На прототипе клиент обнаружил, что 4 из 5 офис-менеджеров не понимают групповой заказ. Изменили логику — переделали интерфейс ещё в Figma.
• На MVP получили двух платящих клиентов в первые 10 дней после запуска.
• Сэкономили примерно 200 000 ₽, которые в стандартном сценарии «сразу делаем MVP» ушли бы на переделку UX уже после релиза.

Итого 700 000 ₽ против 800 000 ₽ — но с уже проверенной UX-логикой и платящими клиентами.

Чек-лист: что вам нужно прямо сейчас

Ответьте честно на вопросы:

1. Хочу ли я в ближайшие 2 месяца получить платящих клиентов? Если да → MVP.

2. Понятно ли уже сейчас, как должен выглядеть интерфейс? Если нет → сначала прототип, потом MVP.

3. Есть ли у меня внутри команды/среди инвесторов споры о том, как продукт должен выглядеть? Если да → сначала прототип.

4. Бюджет до 200 000 ₽ и срок до 3 недель? Прототип. На MVP бюджета не хватит.

5. Нужны ли мне реальные метрики (конверсия, LTV, retention)? Только MVP.

Главный вывод

Прототип отвечает на вопрос «как это должно работать?» MVP отвечает на вопрос «будут ли за это платить?»

Это два разных продукта под две разные стадии. Если вы их путаете — переплачиваете либо за то, что не нужно (прототип, когда сразу нужен MVP), либо за переделку (MVP без проверки UX). В обоих случаях речь идёт о сотнях тысяч рублей.

В Hexbit мы на первом созвоне всегда задаём вопрос «что вы хотите проверить?» — и уже из ответа собираем, нужен прототип, MVP, или комбинированный план из двух этапов. Это первый и самый важный фильтр на пути к запуску продукта.