MVP в разработке: что это, сколько стоит и как запустить

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

Что такое MVP простыми словами

Термин Minimum Viable Product («минимально жизнеспособный продукт») популяризировал Эрик Рис в книге «Бизнес с нуля» (The Lean Startup, 2011). Логика простая: вместо того чтобы год строить продукт по своим представлениям о рынке, команда выпускает минимальную версию, измеряет поведение пользователей и принимает решение на цифрах. Цикл «создать → измерить → научиться» повторяется, пока продукт не найдёт свой рынок или пока не станет ясно, что идея не работает.

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

MVP, прототип, пилот и полноценный продукт: в чём разница

Четыре понятия часто смешивают, а от них зависят бюджет, сроки и ожидания. Коротко: прототип отвечает на вопрос «понятно ли это», проверка концепции (PoC) — «технически возможно ли», MVP — «нужно ли это рынку», пилот — «работает ли это у конкретного заказчика в его процессах».

В B2B эти стадии часто идут подряд: прототип согласуют с ключевыми пользователями, MVP запускают на одном отделе или трёх клиентах, затем пилот превращается в продукт. В потребительских сервисах прототип нередко пропускают и сразу тестируют MVP на трафике.

Виды MVP: какой выбрать под гипотезу

Писать код — не единственный и часто не первый способ проверить идею. Чем дешевле формат, тем быстрее ответ, но тем меньше он говорит о повторных покупках и удержании.

Лендинг-тест (smoke test)

Одна страница с описанием продукта, ценой и кнопкой «записаться», «оформить предзаказ» или «оставить заявку», плюс небольшой рекламный бюджет в Яндекс Директе или посевы в Telegram. Проверяет интерес и готовность оставить контакт. Близкий формат — видео-MVP: Dropbox до запуска продукта собирал лист ожидания через ролик с демонстрацией работы сервиса. Срок — 1–2 недели, бюджет — лендинг плюс трафик.

«Консьерж»

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

«Волшебник из страны Оз»

Снаружи пользователь видит готовый продукт, а внутри процессы выполняют люди: заявки обрабатывает оператор, «алгоритм» подбора — аналитик с таблицей. Так начинал Zappos: основатель выкладывал фото обуви из обычных магазинов и выкупал пары под каждый заказ. Хорош, когда нужно проверить ценность до дорогой автоматизации, например ИИ-функции.

No-code и low-code прототип

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

Кодовый MVP

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

Коротко по срокам и выбору:

• Лендинг-тест — интерес, цена, канал привлечения; 1–2 недели; когда идея на бумаге и нужно понять, есть ли спрос.
• Консьерж — реальная задача клиента и готовность платить; запуск сразу; услуги, B2B, сложный клиентский путь.
• Волшебник из страны Оз — ценность автоматизированного сценария; 2–4 недели; когда дорогая автоматизация или ИИ под вопросом.
• No-code / low-code — сценарий на первых клиентах; 2–6 недель; простая логика, мало ролей и интеграций.
• Кодовый MVP — использование, удержание, оплата; 1,5–3 месяца; ценность в логике и данных, есть план развития.

Как определить минимальный набор функций MVP

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

1. Сформулируйте гипотезу в проверяемом виде. Не «клиентам нужна онлайн-запись», а «владельцы небольших автосервисов будут платить 3 000 ₽ в месяц за онлайн-запись, если она сократит пропущенные звонки».
2. Задайте метрику успеха и порог до старта. Например: 20 платящих сервисов за 2 месяца, 40% из них делают 10+ записей в неделю. Порог фиксируют заранее, иначе любой результат потом назовут успехом.
3. Опишите один ключевой сценарий целиком. Путь пользователя от входа до результата: нашёл → зарегистрировался → сделал действие → получил ценность → заплатил.
4. Разложите функции по MoSCoW. Must — без этого сценарий не проходит; Should — желательно, но можно вручную; Could — приятно; Won't — точно не в этой версии. В MVP идёт только Must.
5. Для каждой функции спросите: «Можно ли это сделать руками?» Выставление счетов, модерация, онбординг, отчёты на первых 50 клиентах часто проще делать вручную.

Этапы разработки MVP и сроки

Кодовый MVP проходит те же этапы, что и любой программный продукт, но каждый из них короче и жёстче ограничен по объёму. Ниже — типовой график для веб-сервиса или приложения с одной-двумя интеграциями.

1. Аналитика (discovery), 1–2 недели. Гипотеза, метрики, роли, ключевой сценарий, карта функций Must/Should.
2. Прототип и дизайн, 1–2 недели. Кликабельный прототип ключевых экранов, простой UI на готовой системе компонентов.
3. Разработка, 4–8 недель. Бэкенд, интерфейс, админка, 1–3 интеграции; спринты по 2 недели с демонстрацией.
4. Тестирование — параллельно с разработкой плюс 1 неделя. Ключевые сценарии, оплата, права доступа, мобильные устройства.
5. Запуск и сбор данных — от 1 месяца наблюдения. Боевой сервер, аналитика событий, публикация в сторах при необходимости.

В сумме до запуска — от 1,5–2 месяцев для веб-сервиса и от 2 месяцев для мобильного приложения. Если подрядчик обещает кодовый MVP с кабинетом, оплатой и админкой за 2 недели, стоит уточнить, что именно будет сделано и на чём.

Сколько стоит MVP и от чего зависит цена

Цена MVP зависит не от количества экранов, а от объёма логики: ролей, статусов, расчётов, интеграций и требований к данным. Ориентиры по трём типам проектов:

Нижние границы — ориентир по открытым прайсам подрядчиков, у разных исполнителей они сильно отличаются. Разброс объясняется составом работ: в нижней части вилки обычно один сценарий без админки, без интеграций, с шаблонным дизайном и минимумом тестирования. Точную стоимость можно назвать только после аналитики: одинаковая на словах «онлайн-запись» стоит по-разному с оплатой и без, с одной ролью и с тремя.

Что сильнее всего двигает цену:

• Платформа. Веб, iOS, Android или все сразу. Для мобильного MVP кроссплатформенная разработка на Flutter или React Native обычно дешевле двух нативных приложений — подробнее в разделе разработка мобильных приложений.
• Роли и права. Клиент + администратор — базовый вариант; каждая новая роль (исполнитель, партнёр, менеджер) добавляет интерфейсы и проверки доступа.
• Интеграции. ЮKassa, 1С, СДЭК, amoCRM, карты — каждая даёт 2–5 дней работы и риски на стороне внешнего API.
• Уровень дизайна. Готовая система компонентов против уникального UI с анимациями — разница до 30–40% бюджета на интерфейс.
• Модель договора. Фиксированная цена требует чёткого объёма, почасовая оплата даёт гибкость при меняющихся требованиях — сравнение в статье Fixed Price или Time & Material.

Пример бюджета MVP по функциям

Условный проект: веб-сервис онлайн-записи для сети автосервисов. Клиент выбирает услугу и время, оплачивает предоплату, получает напоминание; оператор видит расписание в админке. Расчёт — по трудозатратам при ставке студии АП-ИМ 2 500 ₽/час; у других подрядчиков ставка отличается.

Где можно сэкономить без ущерба для проверки гипотезы: убрать онлайн-оплату и выставлять счёт вручную (−60 000 ₽), оставить только e-mail-уведомления (−15 000 ₽ ориентировочно), взять готовую библиотеку компонентов вместо собственного дизайна. Где экономить нельзя — в следующем разделе.

Как не превратить MVP в технический долг

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

Что делать после запуска MVP: метрики и решение pivot или persevere

Запуск MVP — начало проверки, а не финиш. Решение принимают по заранее заданным метрикам, а не по впечатлениям от первых отзывов.

• Активация — доля зарегистрированных, кто дошёл до ключевого действия (первая запись, первый заказ).
• Удержание — сколько пользователей возвращаются через неделю и месяц. Для MVP это главный сигнал ценности.
• Конверсия в оплату и готовность платить заявленную цену.
• Стоимость привлечения клиента в выбранном канале по сравнению с его выручкой.
• Качественная обратная связь — 10–15 интервью с активными и ушедшими пользователями.

Дальше три варианта. Persevere (продолжать) — метрики выше порога: наращиваем функции из списка Should. Pivot (разворот) — продукт используют не так или не те, кого ожидали: меняем сегмент, сценарий или модель монетизации. Стоп — метрики далеко от порога после нескольких итераций: закрываем проект, сэкономив бюджет полноценной разработки. Популярный ориентир для потребительских продуктов — тест Шона Эллиса: если 40% и более пользователей будут «очень разочарованы», лишившись продукта, это признак соответствия продукта рынку.

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

Типовые ошибки при разработке MVP

• MVP без гипотезы. Продукт запустили, а что считать успехом — непонятно. Любые цифры можно трактовать в свою пользу.
• «Ещё одна маленькая функция». Объём растёт в процессе, срок уходит с 2 месяцев на 6, бюджет — вдвое.
• Сырой продукт вместо минимального. Ошибки в ключевом сценарии отпугивают пользователей, и провал списывают на идею, хотя виновато качество.
• Нет аналитики с первого дня. Без событий в Метрике или продуктовой аналитике через месяц нечего анализировать.
• Нет канала привлечения. MVP сделан, но показать его некому. Бюджет на первые 100–500 пользователей закладывают вместе с разработкой.
• Код и доступы у подрядчика. Продукт нельзя развивать без исполнителя, который его написал.

Чек-лист запуска MVP

• Гипотеза сформулирована: кто, какую проблему решает, сколько готов платить
• Метрика успеха и пороговое значение зафиксированы до старта
• Выбран самый дешёвый вид MVP, который проверяет гипотезу
• Описан один ключевой сценарий от входа до результата
• Функции разложены по Must/Should/Could, в работе только Must
• Для каждой функции проверено, нельзя ли сделать её вручную
• Модель данных, авторизация и права доступа спроектированы как для продукта
• Персональные данные хранятся в РФ, есть согласия и политика обработки
• Настроены события аналитики и резервное копирование
• Исходный код, сервер и аккаунты оформлены на заказчика
• Заложен бюджет на привлечение первых пользователей
• Назначена дата решения: продолжать, разворачиваться или остановиться

Итог

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