MVP (Minimum Viable Product) — это первая работающая версия продукта, которая проверяет ключевую гипотезу с минимальными затратами. Не прототип, не мокап, не презентация — а реальный продукт, которым пользуются реальные люди. 30 дней — жёсткий, но реалистичный срок для запуска, если подойти системно.

Неделя 1: Формулировка и валидация гипотезы

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

Проведите 10–15 проблемных интервью с представителями целевой аудитории. Не предлагайте решение — спрашивайте о проблеме. Как они решают её сейчас? Сколько времени и денег тратят? Что пробовали и что не сработало? Цель — подтвердить, что проблема реальна, болезненна и достаточно распространена.

После интервью определите одну ключевую функцию — то единственное, что делает продукт ценным. Не три функции, не пять — одну. Всё остальное — на потом. Идея Netflix начиналась с одной функции: отправка DVD по почте. Dropbox — с синхронизации одной папки.

Неделя 2: Проектирование и выбор стека

Нарисуйте user flow — путь пользователя от первого экрана до достижения результата. Не в Figma на 50 экранов, а ручкой на бумаге за 30 минут. Сколько шагов от входа до ценности? Если больше пяти — упрощайте.

Выбор технологий для MVP диктуется скоростью, а не масштабируемостью. Масштабируемость — проблема роста, а не старта. Проверенный стек для веб-MVP: Next.js + Supabase (или Firebase) + Vercel. Для мобильного — React Native или Flutter. Для лендинга с формой — Tilda или Webflow.

No-code инструменты — легитимный выбор для MVP. Bubble, Glide, Softr позволяют собрать рабочий продукт за неделю без единой строки кода. Если гипотеза подтвердится — всегда можно переписать на нормальном стеке. Если не подтвердится — сэкономили месяцы разработки.

Неделя 3: Разработка

Семь дней на код — это мало, и именно поэтому дисциплина критична. Разбейте функциональность на задачи, оцените каждую в часах и распределите по дням. Ежедневный чекпоинт: что готово, что блокирует, что можно вырезать.

Три правила скорости: никаких кастомных дизайн-систем — используйте готовые UI-киты (shadcn/ui, Tailwind UI, Ant Design). Никакой кастомной авторизации — Auth0, Clerk, Supabase Auth. Никаких ручных деплоев — CI/CD с первого дня через Vercel, Railway или Fly.io.

Вырезайте всё, без чего продукт может работать. Админ-панель? Не нужна — редактируйте через базу данных напрямую. Профили пользователей с аватарками? Достаточно имени и email. Красивые анимации? Подождут. Единственное, на чём нельзя экономить — это основная ценность продукта.

Неделя 4: Запуск и первые пользователи

Запуск MVP — это не пресс-релиз и не Product Hunt (пока). Это 20–50 первых пользователей, которые протестируют продукт и дадут фидбек. Где их найти: участники проблемных интервью (вы им уже обещали показать решение), тематические Telegram-группы и Discord-серверы, LinkedIn-публикация с описанием проблемы.

Настройте аналитику до запуска, а не после. Минимальный набор: Posthog или Amplitude для трекинга действий, Hotjar для записи сессий, простая форма обратной связи внутри продукта. Вам нужно ответить на три вопроса: пользователи доходят до ключевой функции? Возвращаются ли на следующий день? Готовы ли платить?

Retention важнее acquisition. Если из 50 первых пользователей 5 возвращаются каждый день — это сильный сигнал. Если все 50 зарегистрировались и ушли — проблема не в маркетинге, а в продукте.

После запуска: метрики решают

Определите одну North Star метрику — число, которое лучше всего отражает ценность продукта для пользователя. Для мессенджера — количество отправленных сообщений. Для CRM — количество созданных сделок. Для аналитического инструмента — количество сгенерированных отчётов.

На основе данных первых 2–3 недель принимайте решение: pivot (смена направления), persevere (продолжение с текущей гипотезой) или kill (закрытие). Не привязывайтесь эмоционально к продукту — привязывайтесь к данным.

Типичные ошибки

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

Фичекрип — добавление функций до проверки основной. Каждая новая фича — это дни разработки и усложнение продукта. Держите scope железной рукой.

Запуск без метрик — полёт вслепую. Если вы не знаете, сколько пользователей дошло до ключевого действия — вы не знаете, работает ли продукт.

30 дней — это достаточно, чтобы узнать, решаете ли вы реальную проблему. Не достаточно, чтобы построить бизнес — но достаточно, чтобы понять, стоит ли его строить.