MVP — это способ проверить одну гипотезу о продукте, а не урезанная версия будущей системы. Отсюда главный критерий: в MVP входит только то, без чего гипотезу не проверить, и не входит ничего, что просто «пригодится потом». Средний срок сборки такого продукта — от нескольких дней до полутора-двух месяцев, и зависит он не от количества экранов, а от того, насколько узко сформулирован вопрос.
Почему вопрос возникает
Формулировка «минимальный жизнеспособный продукт» сбивает с толку двумя словами сразу. «Минимальный» читается как «дешёвый и неполный», «продукт» — как «то, что можно продавать». В итоге под MVP чаще всего заказывают обычный проект, из которого вырезали половину функций ради экономии. Получается система, которая ничего не проверяет: пользоваться ей неудобно, а отказ человека от сценария невозможно отличить от отказа от плохой реализации.
Разница видна на вопросе: что именно станет известно после запуска? У урезанной версии ответа нет — она просто работает хуже полной. У MVP ответ формулируется до начала работы одной фразой: люди готовы оставлять заявку без звонка менеджера; лаборатория примет заказ через форму, а не по почте; подписка продлевается на второй месяц. Всё, что не помогает получить этот ответ, из объёма выпадает.
Что такое MVP в контексте разработки продукта
Полезнее считать MVP не стадией продукта, а инструментом измерения. У инструмента есть три обязательные части.
Гипотеза. Утверждение, которое может оказаться ложным. «Клиентам нужен удобный сервис» гипотезой не является — его нельзя опровергнуть. «Клиент оформит заказ на анализ воды сам, без консультации» — является: либо оформит, либо нет.
Метрика. Одно число и порог, при котором гипотеза считается подтверждённой. Не набор дашбордов, а одна величина: доля доведённых до оплаты заказов, количество повторных входов на второй неделе, стоимость первой заявки.
Срок. Окно, за которое набирается достаточно данных. Без срока проверка превращается в бесконечную доработку: цифра не нравится — добавили функцию — снова ждём.
Гипотез в голове обычно пять-шесть, и соблазн проверить их разом велик. Проверять стоит одну. Когда в одном запуске смешаны новый сценарий, новая аудитория и новый способ оплаты, провал не говорит ничего: непонятно, какая из трёх частей не сработала. Остальные гипотезы никуда не денутся — они становятся очередью на следующие итерации.
Что входит в разработку MVP
Продуктовая часть
Самый недооценённый этап и обычно самый короткий по календарю. Здесь фиксируются гипотеза, метрика, порог и срок; описывается один сквозной сценарий от входа до целевого действия; отсекается всё, что в этот сценарий не входит. Отдельно проговаривается, что будет сделано руками: подтверждение заказов, выставление счетов, рассылка — на этапе проверки ручная операция дешевле интеграции и быстрее меняется.
Результат этапа — не техническое задание на сто страниц, а короткий документ, по которому видно, что именно считать успехом.
Прототип
Кликабельная схема экранов без кода. Нужна, чтобы поймать логические дыры до сборки: непонятно, откуда пользователь берёт номер заказа; форма требует данных, которых у человека нет под рукой; целевое действие спрятано на третьем шаге. Правка на этой стадии стоит минут, та же правка после сборки — дней.
Сборка
Здесь решается вопрос платформы. Конструктор вроде Tilda оправдан, когда гипотеза про спрос и продажи: витрина, каталог, форма, оплата. Интернет-магазин анализов воды на Tilda запускался два месяца и за период работы дал 2,9 млн ₽ выручки при 267 оплаченных заказах и среднем чеке 6 125 ₽ — рекламные вложения окупились в 4,4 раза. Проверка спроса не требовала своего кода.
Свой код нужен, когда гипотеза про сценарий, которого в конструкторе нет: личный кабинет, расчёты, обработка данных, автопубликация. Скорость при этом не обязательно падает. Сайт Getsman — 8 страниц на своём коде — собран за 2 дня, вместе с журналом, который дорос до 87 статей с автопубликацией. Оговорка честная: два дня получаются там, где заранее известна структура и не нужно ничего согласовывать по кругу.
Запуск и тестирование
MVP без трафика — не MVP, а макет. В объём входит настройка счётчика, разметка целевого действия и первый источник посетителей: реклама, рассылка по существующей базе, поисковый спрос. Дальше — окно наблюдения и решение по заранее выбранному порогу: развивать, менять гипотезу или закрывать.
Полезная деталь: трафик не всегда стоит денег. Сайт услуг лаборатории на 20+ направлений собрал 551 заявку через форму при 4 531 визите вообще без рекламного бюджета — источником был поисковый спрос. Если ниша узкая, проверка гипотезы может обойтись без рекламных расходов.
Сколько стоит и от чего зависит
Своих публичных цен у Dodigi нет, поэтому ориентир ниже — по опубликованным прайсам студий.
| Что собирается | Опубликованный диапазон |
|---|---|
| Лендинг для проверки спроса | от 100 тыс. ₽ |
| Многостраничный сайт, интернет-магазин | от 200 тыс. ₽ |
| Сайт на Тильде, широкая вилка по объёму | 250 тыс. — 1,5 млн ₽ |
| Веб-сервис со своим кодом | от 2 млн ₽, от 3 месяцев |
| Мобильное приложение | от 900 тыс. ₽, от 2 месяцев |
| Поддержка и развитие после запуска | от 2 000 ₽/час |
Разброс объясняется не жадностью подрядчиков, а тем, что словом MVP называют вещи, отличающиеся в двадцать раз по объёму. Лендинг с формой и сервис с личным кабинетом, ролями и интеграцией с учётной системой — разные проекты, даже если оба называются «минимальными».
Смещает смету вверх обычно не дизайн, а три вещи: количество ролей (гость, клиент, сотрудник, администратор — каждая добавляет экраны и правила доступа), интеграции с чужими системами и требования к данным, если в проекте есть персональные сведения или платежи.
Когда MVP не нужен
Спрос уже доказан. Если очередь на услугу есть и заявки приходят в мессенджеры, проверять нечего — вопрос не «купят ли», а «как перестать терять». Тогда задача другая: не MVP, а рабочая версия сразу, с оплатой и учётом.
Задача внутренняя. Для процесса внутри компании гипотезы про рынок не существует. Здесь важнее разобрать процесс до автоматизации: сколько шагов, кто за что отвечает, где данные вводят дважды. Автоматизация поверх неописанного процесса даёт систему, которой не пользуются, — сотрудники тихо возвращаются к таблицам.
Гипотезу можно проверить без разработки. Самый частый случай. Спрос проверяется страницей с формой и небольшим рекламным бюджетом; готовность платить — предзаказом; сценарий — ручной обработкой первых двадцати обращений в переписке. Если ответ получается без кода, то разработка на этом этапе покупает не знание, а отсрочку.
Проверять нечего, потому что решение принято. Бывает, что MVP заказывают, чтобы обосновать уже сделанный выбор. В таком случае честнее сразу планировать полноценный продукт: измерения всё равно ни на что не повлияют.
На что смотреть
Смета. Превышение на 20–40% к моменту сдачи — типичная история, и растёт она обычно не на новых функциях, а на том, что не проговорили: миграции старых данных, доработке после интеграции, правках вёрстки под мобильные. Помогает простое правило: до старта зафиксировать, что именно НЕ входит в объём, и договориться, как оцениваются добавления по ходу.
Сроки. «Месяц по договору — сдал через полгода» встречается часто. Страховка — не штрафы, а короткие контрольные точки: работающий кусок каждую неделю-полторы, а не одна демонстрация в конце.
Зависимость от исполнителя. Формулировка «кроме нас никто в этом коде не разберётся» описывает не сложность, а риск. У MVP это особенно неприятно: продукт по определению временный, а переписывать его придётся уже с другой командой.
Доступы и исходники. Домен, хостинг, репозиторий, аккаунты аналитики и рекламных кабинетов должны быть оформлены на заказчика с первого дня, а не переданы «когда всё закончим». Ситуация, когда владелец бизнеса не может войти в админку собственного сайта, разрешается тяжело и долго.
Отчётность. Клики и визиты в отчёте вместо заявок и оплат означают, что метрику не выбрали заранее. Для MVP это критично: без целевого числа запуск не отвечает на вопрос, ради которого затевался.
Вопросы и ответы
Чем разработка MVP отличается от прототипа? Прототип — кликабельная схема без кода, он проверяет понятность интерфейса и ловит логические дыры. MVP работает по-настоящему, с реальными пользователями и деньгами, и проверяет поведение: доходят ли до целевого действия, возвращаются ли. Прототип обычно предшествует MVP и занимает дни, а не недели.
Сколько времени занимает разработка MVP для стартапа? От пары дней до полутора-двух месяцев в зависимости от того, что собирается. Витрина с оплатой на конструкторе — недели; сайт на своём коде с известной структурой собирался за 2 дня; сервис с личным кабинетом и интеграциями, по опубликованным прайсам студий, начинается от 2–3 месяцев. Больше всего времени съедают не экраны, а согласования и неописанные требования.
Как понять, что MVP провалился, а не просто «мало трафика»? По порогу, зафиксированному до запуска, и по объёму данных. Если целевого действия достигают единицы при сотнях визитов — это ответ по гипотезе. Если визитов десятки, вывод делать рано: сначала нужен трафик, иначе измеряется случайность. Поэтому источник посетителей планируется вместе с продуктом, а не после.
Что делать с MVP после проверки — дорабатывать или переписывать? Зависит от того, что подтвердилось. Если гипотеза сработала и нагрузка растёт, разумно переписывать несущие части, а интерфейс сохранить. Если сработала частично — дешевле поменять сценарий на том же коде. Планировать переписывание заранее не стоит: половина MVP закрывается, и вложения в архитектуру для них не окупаются.
Можно ли проверить гипотезу без разработки вообще? Часто да. Страница с формой, объявление с ценой, ручная обработка первых обращений, предзаказ — всё это даёт ответ на вопрос «готовы ли платить» без строчки кода. Разработку имеет смысл начинать, когда ручной способ упирается в объём или когда проверяемый сценарий без интерфейса просто не существует.
Разбор гипотезы, выбор платформы и оценка объёма — контакты. Ответ в течение дня.