Что делать после запуска MVP: план на первые 12 месяцев

Запуск MVP — это не финиш, а старт. И именно здесь большинство фаундеров совершают главную ошибку: начинают вкладываться в привлечение, когда продукт ещё разваливается под теми, кто уже пришёл.

90% запускают продукт и думают: «теперь больше пользователей». Реальность другая: первые сто пользователей уходят из-за проблем, о которых вы даже не подозреваете. Пока вы считаете DAU, они тихо перестают открывать приложение.

Три фазы после MVP

После запуска не бывает одного «дальше расти». Есть три фазы, и у каждой свои метрики. Перепрыгните через этап — заплатите потом.

Фаза 1: Validation (недели 1–8)

Ваша работа — понять, действительно ли люди пользуются продуктом или просто «попробовали один раз». Метрики простые:

• DAU / Total Users — сколько возвращаются ежедневно;
• retention curve (день 1, 7, 30) — возвращаются или уходят;
• feature adoption rate — какие функции реально нужны;
• ранний NPS — порекомендовали бы вас.

Золотое правило: если удержание на 7-й день меньше 20%, вы не идёте дальше. Чините продукт, а не «растите аудиторию».

Фаза 2: Reliability (месяцы 2–4)

Теперь продукт должен выдержать настоящий трафик. «Работает у моих родителей» — не считается.

• Uptime > 99.9% — падение убивает доверие;
• Response time < 200 мс — люди не ждут;
• Error rate < 0.1% — каждая ошибка забирает пользователя;
• Помните про базу данных: это тихое узкое место.

Фаза 3: Scale (месяцы 4–12)

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

Технический чек-лист: 7 пунктов до масштабирования

Вот что должно быть готово до того, как вас настигнет трафик.

1. Стратегия базы данных

• Индексы на частые запросы;
• connection pooling;
• read replicas, если чтений больше, чем записей;
• кэш-слой (Redis).

2. Rate Limiting для API

Один пользователь с 10 000 запросов в минуту может обойтись дороже, чем вы думаете.

3. Фоновые задачи

Всё, что может не быть синхронным, — в очередь. Почта, отчёты, обработка файлов.

4. Наблюдаемость

• централизованные логи;
• бизнес-метрики, а не только технические;
• алерты, на которые не стыдно реагировать.

5. Базовый уровень безопасности

• надёжная авторизация — не придумывайте свою, берите JWT или OAuth;
• HTTPS везде;
• валидация ввода;
• автоматическое обновление зависимостей.

6. CI/CD без страха

• ежедневные деплои без стресса;
• откат в один клик;
• feature flags, чтобы тестировать в проде.

7. Контроль расходов

Знать, сколько стоит каждый пользователь, получать алерты о перерасходе и вовремя оптимизировать ресурсы.

Кого нанимать первым (если на счету $50k после валидации)

Приоритеты не такие, как кажется.

Первым — capable full-stack разработчик

• умеет деплоить;
• закрывает инциденты;
• оптимально: один senior или двое middle.

Вторым — продуктовый человек

Тот, кто решает, что строить, слушает пользователей и вообще чувствует продукт. Не дизайнер, не проджект-менеджер — именно product sense.

Третьим — первый сейлз

Когда product-market fit уже есть, нужен кто-то, кто будет приводить клиентов.

Что пока не нужно

• «известный CTO»;
• команда из пяти разработчиков;
• отдельный QA;
• project manager.

Готовы ли вы масштабироваться

Есть чёткие сигналы.

Пора

• Ретеншн выше 40% на первой неделе;
• NPS выше 30;
• есть лист ожидания;
• пользователи просят конкретные функции, а не «сделайте лучше»;
• вы теряете деньги из-за технических ограничений.

Рано

• пользователи не возвращаются после первого дня;
• вы не знаете, почему они уходят;
• каждый деплой что-то ломает;
• у вас нет бизнес-метрик.

Прежде чем думать «как привлечь больше пользователей», убедитесь, что те, кто уже пришёл, не уходят. Запустить — легко. Удержать, выдержать нагрузку и не сойти с ума — это и есть настоящая работа.