от ответа — к продукту
После MVP: развивать продукт, не раздувая его
MVP отвечает на вопрос. Дальше начинается другая работа: выбирать, что строить, когда каждая фича стоит реальных денег.
После запуска MVP начинается этап, к которому мало кто готовится: продукт уже живой, пользователи реальные, а ресурсов по-прежнему мало. Первые настоящие пользователи находят то, чего не нашёл ни один тест. Список хотелок растёт быстрее, чем список оплат. Технические срезы, честно сделанные ради скорости, начинают напоминать о себе. Главный риск этого этапа — не баги, а расфокус: строить всё подряд и не понять, что из этого работает.
Так я веду Castolly — собственный продукт после MVP: итерации от реального использования, метрики вместо ощущений, техдолг гасится тогда, когда начинает мешать, а не по расписанию. Тот же подход предлагаю на сопровождении: короткие циклы «гипотеза → изменение → цифры», где следующая итерация выбирается по данным. И если данные говорят «дальше вкладывать не стоит» — я скажу это раньше, чем вы потратите следующий бюджет.
- баги и ошибки — чиню за свой счёт, это моя ответственность
- мелкие правки: тексты, поля, формы, права, простые отчёты
- инциденты прода: разбираю, восстанавливаю, объясняю причину
- вопросы по работе системы — напрямую мне, без тикет-системы
Это гарантия на мою работу, а не тариф: чиню и правлю то, что запустил, за свой счёт. Ответ — в течение рабочего дня, напрямую мне.
Что происходит с продуктом после запуска
- Реальные пользователи ломают сценарии, которые «точно работали».
- Хотелки пользователей и фичи, за которые платят, — разные списки.
- Техдолг MVP начинает стоить времени в каждой новой задаче.
- Решения принимаются «на глаз», потому что аналитики нет.
- Основание, собранное для проверки, не готово к росту нагрузки.
Сигналы после MVP и что они значат
| Сигнал | Что это значит | Что делаем |
|---|---|---|
| Пользователи возвращаются сами | Ядро ценности найдено | Укрепляем основание, готовим рост |
| Регистрируются, но не остаются | Ценность не доносится или не та | Итерации онбординга, разговоры с ушедшими |
| Каждая правка тянет три соседних | Техдолг начал кусаться | Точечный рефакторинг, не переписывание всего |
| Просят фичи, но не платят | Гипотеза цены не проверена | Проверяем оплату раньше, чем строим |
| Метрики стоят месяцами | Продукт упёрся | Честный разговор: пивот, пауза или стоп |
Что дальше
Услуга: Веб-приложения и сервисы Сколько стоит построить: MVP продукта Кейс по теме: Castolly — AI-конвейер контента для подкастов
Частые вопросы
- MVP делали не вы. Возьмёте развитие?
- После аудита кода — как и любую чужую систему. MVP часто написан быстро, и это нормально: он для того и делался. Аудит отвечает на один вопрос — можно ли на этом основании строить дальше или дешевле пересобрать ядро. Ответ вы получаете письменно, с аргументами.
- Когда MVP пора переписывать?
- Когда стоимость изменений устойчиво растёт: каждая новая фича трогает половину кода. Пока правки локальны — развивайте, переписывание не окупится. Решение принимается по динамике стоимости задач, а не по эстетическим претензиям к коду.
Система уже есть?
Расскажите, что за система и что с ней происходит — скажу честно, возьму ли её на сопровождение и с чего начать.
Обсудить проект