Что реально успеть в MVP за 2–4 недели

«MVP за месяц» звучит как маркетинг. На практике срок рабочий — но только если понимать, что в него помещается, а что нет. Разбор без обещаний.

Что помещается

За 2–4 недели реально собрать продукт, у которого есть:

один сквозной сценарий целиком — пользователь пришёл, зарегистрировался, сделал главное действие, получил результат;
вход — почта или телефон, при необходимости роли;
основные экраны для этого сценария, адаптивные;
аналитика — события и воронка, чтобы гипотеза проверялась данными, а не ощущениями;
одна-две интеграции — оплата, уведомления или CRM;
деплой в прод — на домене, с сертификатом, с базовым мониторингом.

Этого достаточно, чтобы дать продукт живым людям, показать инвестору и получить фактический ответ, работает идея или нет.

Что не помещается

Честный список того, что не влезает в месяц:

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

Что съедает срок незаметно

Опыт показывает: срок ломают не задачи разработки, а вещи вокруг.

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

Доступы. Ключи к платёжке, доступ к CRM, права в облаке, домен. Каждый добытый на третьей неделе доступ — минус дни. Собирать надо в первый день.

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

Контент. Тексты, фото, описания, юридические документы. Обычно всплывает в последний момент и обнаруживается, что их некому написать.

Расширение по ходу. «Раз уж делаем, давайте ещё вот это». Каждое такое «ещё» стоит срока — и это нормально, если решение принимается осознанно, а не по инерции.

Как повысить шансы уложиться

Ограничьте скоуп до одного сценария. Не «платформа для X», а «пользователь делает Y и получает Z». Всё остальное — во вторую итерацию.

Определите метрику успеха заранее. Что должно произойти, чтобы гипотеза считалась подтверждённой? Без этого MVP превращается в бесконечную стройку.

Соберите доступы в первый день. Списком, все сразу.

Назначьте одного человека с правом решать. Не комитет.

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

Чем MVP отличается от прототипа

Путаница дорого стоит, поэтому зафиксируем:

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

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

И главное

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

Пишу из практики студии MKDGRUPP: собираем MVP за 2–4 недели — настоящий код на React/Next.js/Node, аналитика с первого дня, фикс-цена, репозиторий у вас. Оценка и план за час: mkdgrupp.ru/uslugi/mvp.