MVP за 4–6 недель: методология без воды

§ 01Что такое MVP (и что им не является)

Minimum Viable Product — минимально жизнеспособный продукт. Слово «жизнеспособный» здесь ключевое, но его чаще всего теряют. Получается «minimum product» — минимальный продукт. Это не то же самое.

Жизнеспособный значит: пользователи могут им пользоваться, получать результат, платить деньги. Он живой. Урезанный, с кучей ограничений, но работающий. Без багов на критическом пути.

Минимальный значит: функциональности ровно столько, сколько нужно для одного ключевого сценария. Всё остальное — в бэклог, не в релиз.

Что MVP не является:

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

Основной вопрос, на который отвечает MVP: стоит ли продолжать? Если ответ «да» — дорабатываем. Если ответ «нет» — закрываем, сэкономив на дальнейшей разработке. Оба исхода — полезны.

§ 02Три типа MVP: lean, classic, seed-ready

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

Lean-MVP — для первичной валидации

Самая дешёвая и быстрая версия. Цель — понять, что у продукта вообще есть аудитория. Один ключевой сценарий, авторизация (часто через соцсети или magic link), оплата через Stripe Checkout или ЮKassa Link, минимальная админка на коленке.

Срок: 3 недели. Сценарий: один. Пользователей на старте: 50–500. Решения после: продолжать или закрыть. В этой версии нет ни дизайна «вау», ни удобной админки, ни полного онбординга. Главное — работает базовый сценарий и можно взять деньги.

Classic-MVP — для первых переговоров с инвестором

Более зрелая версия. Несколько сценариев, роли (минимум «пользователь» и «админ»), полноценная админка, email-уведомления, интеграция с основной внешней системой, аналитика.

Срок: 4–5 недель. Сценарий: 2–3 связанных. Пользователей: 500–5000 на первом месяце. Решения после: поднимать seed или расти органически. Это уровень MVP, с которым фаундеры идут к инвесторам: продукт уже что-то показывает, метрики есть, история понятна.

Seed-ready MVP — для поднятия раунда

Полноценный продукт с платящими пользователями, рабочими метриками, инфраструктурой, готовой к 10-кратному росту. Платежи, биллинг, онбординг, аналитика, email-маркетинг, поддержка, мониторинг.

Срок: 6 недель. Сценариев: 4–6. Пользователей: тысячи, MRR: десятки тысяч. Решения после: масштабироваться, нанимать команду, брать deal с инвестором.

Три версии отличаются не только скоупом, но и тем, на какой стадии разговора с инвестором или клиентом их показывают. Lean — это «вот идея и первые пользователи». Classic — «вот работающий продукт и первые цифры». Seed-ready — «вот бизнес, вот деньги на столе».

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

§ 03Скоупинг: как резать функциональность

Это самая сложная и самая ценная часть работы над MVP. У основателя в голове есть видение продукта на полгода вперёд. Он хочет всё и сразу. Задача продакта или разработчика — отрезать 80% и оставить ядро.

Методика, которой пользуюсь я:

1. Сформулировать один ключевой сценарий

Не «продукт делает X, Y и Z», а «Маша открывает приложение, делает A, получает B, платит за C, уходит довольной». Один сценарий, один тип пользователя, одна монета обмена ценностью.

Всё, что не в этом сценарии, — не в MVP. Точка.

2. Для каждой функции задать вопрос: без неё ключевой сценарий сломается?

Если сломается — функция обязательна. Если нет — функция в бэклог, не в MVP. Этот вопрос отсекает 70% «нужных» функций. Настройки уведомлений, экспорт в Excel, история версий, тёмная тема, 10 языков, красивый онбординг — почти всё это не ломает сценарий и, значит, не нужно на MVP.

3. Заменить ручным трудом всё, что можно

Админка для модерации контента — откладывается, мы первый месяц модерирую сам в базе данных. Email-шаблоны — откладывается, пишем письма от руки первые 50 пользователей. Подписки с тарифами — откладываются, все покупают одним тарифом. Потом, когда объём вырастет, автоматизируем.

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

4. Использовать готовые решения вместо кастомных

Аутентификация — Auth.js или Clerk, а не своя. Платежи — Stripe Checkout, а не кастомная корзина. Email — Resend или SendGrid. Аналитика — PostHog или Plausible. Мониторинг — Sentry + UptimeRobot. Каждый готовый сервис экономит 3–5 дней разработки.

5. Отложить всё, что ради «красоты»

Сложные анимации, уникальный дизайн с нуля, идеальная мобильная адаптация под iPad-в-ландшафте, поддержка старых браузеров, экран «404 с юмором». Всё это добавляется на второй итерации, если продукт живёт. На MVP — вёрстка чистая, но не вылизанная. Литтера Radix UI или shadcn вместо уникального дизайн-языка. Mobile-first, но не ювелирно.

§ 04Таймлайн MVP по неделям

Типичный таймлайн Classic-MVP на 5 недель, по которому мы работаем:

Неделя 0 — пре-дискавери

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

Неделя 1 — каркас

Разворачиваю инфраструктуру: репозиторий, деплой на Vercel или Hetzner, база Postgres, авторизация через Auth.js. Делаем основные экраны в вёрстке, пока без бизнес-логики. В конце недели клиент уже может зайти, зарегистрироваться, увидеть главный экран.

Неделя 2 — основной сценарий

Бизнес-логика ключевого потока: пользователь делает то, ради чего приходит. API, база, обработка ошибок, валидация. Демо в конце недели — можно пройти сценарий от начала до конца вручную.

Неделя 3 — платежи и уведомления

Stripe или ЮKassa, email-подтверждения, базовый онбординг. В конце недели можно заплатить реальные деньги и получить доступ.

Неделя 4 — админка и полировка

Минимальная админка для фаундера: список пользователей, ключевые действия, экспорт в CSV. Подключение аналитики и мониторинга. Исправление багов, найденных на демо-сессиях.

Неделя 5 — запуск и первые пользователи

Финальное тестирование на продакшн-окружении. Деплой. Открытие для первой волны пользователей — обычно 20–50 человек из лист ожидания или тёплых знакомых. Мониторинг. Правки по срочным багам первых дней.

После 5-й недели мы не исчезаю. Первые 30 дней поддержки входят в проект: исправление найденных багов, мелкие улучшения по обратной связи. Дальше — либо вторая фаза развития, либо передача вашей команде.

§ 05Метрики после запуска

MVP запущен. Что мерить?

Три метрики, которые скажут, стоит ли продолжать:

1. Конверсия из регистрации в первое целевое действие. Если 40 человек зарегистрировались, сколько дошли до первой покупки, заявки, создания контента — того, ради чего вы делали продукт? Норма — 20–40% на MVP, меньше 10% — плохой знак.
2. Возврат через 7 дней. Сколько пользователей, зарегистрировавшихся в первый день, вернулись на седьмой. Норма — 15–30%, меньше 10% — продукт не даёт value, менять надо его, а не маркетинг.
3. NPS или качественная обратная связь. Лично позвонить или написать 10 первым пользователям. Что работает, что не работает, за что они платят, за что не готовы. Этого больше, чем любые метрики.

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

§ 06Пять ошибок, которые топят MVP

Из более чем 30 MVP, в которых мы участвовал за 7 лет соло-практики, самые частые причины провалов повторяются:

1. Разработка тянется 6 месяцев вместо 6 недель. Обычно потому, что скоуп не зафиксирован и каждую неделю добавляются новые «обязательные» фичи. К концу полугода деньги закончились, продукта нет, фаундер выгорел. Противоядие — фиксированная цена + фиксированный скоуп с самого начала.
2. Слишком большой скоуп на старте. Попытка сделать сразу маркетплейс с двумя сторонами, рекомендательной систенаш и мобилкой. На MVP хватит одной стороны в вебе. Двустороннюю рыночную площадку делают после валидации и с инвестициями.
3. Нет аналитики и обратной связи с пользователями. Продукт запустился, фаундер смотрит в Google Analytics раз в месяц, делает выводы по ощущениям. Через полгода меняет направление на основе интуиции, а не данных. Противоядие — PostHog или аналог с первого дня + еженедельные звонки с первыми пользователями.
4. Нанимают команду до валидации. Сразу 4 человека: разработчик, дизайнер, маркетолог, продакт. На зарплаты уходит основной бюджет до того, как стало понятно, нужен ли продукт. Противоядие — сначала MVP внешним подрядчиком или одним фаундером, потом команда.
5. Вкладываются в маркетинг до работающего продукта. Запуск реклая на лендинг, где «скоро откроется». Собирают лист ожидания в 10 тысяч email, пишут про это в пресс-релизах. Продукт запускается через 4 месяца, из 10 тысяч заходят 800, реально пользуются 20. Деньги потрачены. Противоядие — маркетинг начинается после запуска MVP, не до.

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

Рабочий стек и подход к разработке, который мы используем на MVP-проектах, близок к архитектуре веб-приложений в целом — подробнее об этом в статье веб-приложение или сайт. Если в MVP планируется серьёзная AI-компонента, ещё одна полезная статья — LLM в бизнесе.

Отдельная тема — выбор подрядчика для MVP. Стартап в ранней фазе особенно уязвим к плохому выбору: срыв сроков или сбежавший разработчик может закрыть компанию. Подробно разобрал в статье как выбрать разработчика. Также при MVP часто возникает вопрос бюджета — общие диапазоны цен для разных типов продуктов описаны в статье сколько стоит сделать сайт.

Частые вопросы

Что чаще всего спрашивают основатели до начала работы над MVP.