«MVP за месяц» звучит как маркетинговое обещание, поэтому сразу о главном: да, за 4 недели реально получить работающий продукт с первыми пользователями — если правильно выбрать, что в него входит. Мы в F³ запустили 11 MVP и в этой статье разбираем, как устроен процесс по неделям, что входит в 800 000 ₽, какие ошибки чаще всего срывают первый запуск — и когда MVP вам на самом деле не нужен.
Что такое MVP на самом деле
MVP — это не «урезанный продукт», а инструмент проверки гипотезы: минимальный набор функций, на котором видно, нужен ли продукт рынку. Ошибка большинства проектов — пытаться в первый релиз уложить всё. Результат — полгода разработки и проверка гипотезы, которая могла занять месяц.
Правильный MVP отвечает на один вопрос: будут ли этим пользоваться? Всё, что не помогает ответить, — во вторую итерацию. Поэтому вопрос «что выкинуть из первой версии» важнее вопроса «что добавить».
Почему 4 недели реалистичны: процесс
4 недели работают не потому, что кто-то «пишет код быстрее», а потому что из процесса убрано всё лишнее. Вот типовой план.
- Неделя 1 — разбор и проектирование. Фиксируем гипотезу, сценарии и границы первого релиза; проектируем архитектуру так, чтобы продукт развивался без переписывания. Самая важная неделя: именно здесь решается, уложимся ли в срок.
- Неделя 2 — ядро продукта. Ключевой сценарий от начала до конца: то, ради чего продукт существует. Не десять сценариев наполовину, а один — целиком.
- Неделя 3 — обвязка. Авторизация, админка, уведомления, подключение внешних сервисов. В конце недели — демо на реальных данных.
- Неделя 4 — доводка и запуск. Пограничные случаи, деплой, метрики, выпуск на первых пользователей. Продукт не «сдаётся», а начинает работать.
Два условия, без которых это не работает. Скоуп зафиксирован до старта: изменения не запрещены, но честно обмениваются — добавили одно, убрали другое. И каждую неделю вы видите демо: продукт в процессе, а не «через месяц на сдаче».
Что входит в 800 000 ₽ — и что нет
- Один ключевой сценарий, реализованный целиком: от входа пользователя до результата.
- Веб-интерфейс и админ-панель.
- Деплой, базовый мониторинг и метрики использования — чтобы гипотезу было чем измерять.
- Архитектура «под рост»: MVP — первая версия продукта, а не прототип на выброс. Код развивается дальше без переписывания с нуля.
Не входит в базовую вилку: нативные мобильные приложения, сложные интеграции с корпоративными системами, высоконагруженная архитектура, большая ИИ-составляющая. Это не запретные темы — это отдельные работы, которые оцениваем после брифа, когда понятно, нужны ли они в первой версии вообще. Чаще всего — не нужны.
Отдельный вопрос — команда. Со стороны F³ на MVP работает компактная связка: проектирование, разработка, девопс и менеджер, который держит скоуп. Со стороны заказчика нужен один человек с полномочиями быстро принимать решения — без него четырёхнедельный ритм рассыпается на согласованиях.
11 запущенных MVP: чему они нас научили
За 11 запусков закономерности повторяются. Продукты, которые дошли до пользователей за месяц, почти всегда стартовали с одного сценария — и наращивали остальное итерациями по реальной обратной связи. Продукты, которые буксовали, пытались угадать все потребности заранее.
Второе наблюдение: первая версия — это фундамент, а не черновик. По той же логике мы строим и большие системы: например, система проектного управления для строительной организации росла от ядра — задачи и сроки — к представлениям под каждую роль, без переписывания основания.
И третье: сроки срывает не разработка, а неопределённость. Когда гипотеза сформулирована и скоуп зафиксирован, команда работает предсказуемо; когда каждую неделю появляются «обязательные» новые требования — не спасает ни бюджет, ни размер команды. Поэтому первая неделя уходит на разбор, даже если руки чешутся писать код.
Типовые ошибки первого запуска
- Уложить всё в первый релиз. Каждая «ещё одна фича» отодвигает встречу с реальными пользователями — а именно она отвечает на главный вопрос.
- Полировать до идеала. Интерфейс можно улучшать бесконечно; гипотезу проверяет работающий сценарий, а не идеальные пиксели.
- Строить прототип на выброс. Сэкономленное на архитектуре время возвращается через три месяца — переписыванием с нуля на живом продукте.
- Запускаться без метрик. Если заранее не определить, что считается успехом, любой результат можно объяснить как угодно — и гипотеза остаётся непроверенной.
- Запускаться молча. MVP без плана, кому и как его показать, — это код, а не проверка гипотезы. Первые пользователи — часть скоупа, а не «потом разберёмся».
Когда MVP за 4 недели — не ваш вариант
Честно: если продукт требует сложных интеграций с корпоративными системами, сертификации или высокой нагрузки с первого дня — закладывайте от 3 месяцев и другой бюджет. Например, интернет-площадку под высокую нагрузку для торговой компании мы проектировали сразу с очередями, кэшированием и горизонтальным масштабированием: такие проекты начинаются от 3 000 000 ₽ и живут в другом ритме.
Бывает и обратное: гипотеза уже подтверждена — есть клиенты, выручка, понятный продукт. Тогда задача не «проверить за месяц», а построить систему, которая выдержит рост. Это другой проект с другим планированием, и втискивать его в 4 недели — вредно.
На брифе мы говорим об этом прямо, а не после подписания договора. Есть идея продукта? Опишите её на fcube.io — оценим реалистичный объём первого релиза и вернёмся с планом на 4 недели. Оценка бесплатная.