Как запустить MVP SaaS за 6 недель: план по неделям
Пошаговый план запуска MVP SaaS за шесть недель: что делать на каждой неделе, какой стек выбрать, какие фичи резать и на чём чаще всего срывается срок.
Шесть недель — это не маркетинговая цифра, а срок, в который реально укладывается MVP, если заранее договориться, что именно считать минимально жизнеспособным продуктом. Ниже — план, по которому я веду такие проекты: что происходит на каждой неделе, какие решения принимаются один раз и не пересматриваются, и где обычно теряется время.
Что считать MVP, а что уже нет
MVP — это версия продукта, на которой можно проверить одну ключевую гипотезу: люди готовы платить за то, что вы делаете. Всё, что не участвует в проверке этой гипотезы, переносится в бэклог. Практическое правило: если фичу можно временно заменить ручной работой, письмом или таблицей — на старте её не пишем.
- Входит: регистрация, основной сценарий ценности, оплата, базовая аналитика.
- Не входит: роли и права сложнее «владелец/участник», настройки интерфейса, экспорт во все форматы, мобильное приложение.
- Спорное: интеграции. Оставляем только ту, без которой продукт не работает.
Недели 1–2: discovery, контракт API и каркас
Первые две недели — самые важные: здесь фиксируется объём. Я провожу несколько интервью с потенциальными пользователями, описываю сценарии, а затем сразу фиксирую контракт API. Контракт позволяет дальше вести фронтенд и бэкенд параллельно, не дожидаясь друг друга.
- 3–5 интервью с людьми из целевой аудитории, а не с друзьями.
- Список пользовательских историй с приоритетами и явной отметкой «не в MVP».
- Схема данных и контракт API (OpenAPI или типы TypeScript как источник правды).
- Каркас проекта: репозиторий, окружения, CI, деплой пустого приложения в прод.
Деплой пустого приложения на первой неделе — привычка, которая экономит дни. Когда инфраструктура готова заранее, релиз не превращается в отдельный проект в последний момент.
Недели 3–5: разработка основного сценария
Три недели уходят на то, чтобы пользователь мог пройти путь от регистрации до получения ценности и оплаты. Работаю вертикальными срезами: каждая функция доводится до рабочего состояния целиком, а не «сначала весь бэкенд, потом весь фронтенд».
Скорость берётся не из переработок, а из отказа от лишнего. Каждая отложенная фича — это выигранный день на доведении главного сценария.
- Неделя 3: аутентификация, модель данных, базовые экраны.
- Неделя 4: ключевой сценарий ценности целиком, включая пустые состояния и ошибки.
- Неделя 5: оплата, письма, роли, черновая аналитика событий.
Неделя 6: стабилизация и запуск
Последняя неделя — не «добить фичи», а привести продукт в состояние, в котором его не стыдно показать. Тестирование сквозных сценариев, проверка на реальных данных, мониторинг ошибок, юридические страницы, письма пользователям.
- Сквозные тесты главного сценария и оплаты.
- Мониторинг ошибок и алерты на упавшие платежи.
- Политика конфиденциальности, оферта, контакты.
- События аналитики: регистрация, активация, оплата, отток.
| Этап | Срок | Результат |
|---|---|---|
| Discovery и контракт | Недели 1–2 | Объём зафиксирован, API описан, прод развёрнут |
| Основной сценарий | Недели 3–5 | Пользователь проходит путь до оплаты |
| Стабилизация | Неделя 6 | Тесты, мониторинг, документы, запуск |
Где чаще всего срывается срок
- Объём пересматривают на третьей неделе — и шесть недель превращаются в двенадцать.
- Оплату оставляют на конец, а она всегда сложнее, чем кажется: проратация, возвраты, налоги.
- Заказчик не может быстро принимать решения: одно согласование на три дня съедает полнедели.
- Дизайн рисуют «на весь продукт», а не на экраны MVP.
Если вы планируете такой запуск, самое полезное, что можно сделать до старта разработки, — письменно зафиксировать одну гипотезу и список того, чего в первой версии точно не будет.