MVP за 50 часов: что входит, а что режем
Пятьдесят часов — это не лозунг про скорость, а бюджет. Вечера и выходные дают десять-двенадцать часов в неделю, за год выходит около пятисот пятидесяти. Разделите их на двенадцать попыток — получите пятьдесят на продукт, включая лендинг, оплату и деплой.
Из этого следует всё остальное. Пятьдесят часов — не цель, а ограничение, которое решает, что в продукт войдёт.
Куда уходят пятьдесят часов
Моя раскладка, по опыту первых сборок:
| Блок | Часы | Что сюда входит |
|---|---|---|
| Основная функция | 20 | то, ради чего платят, целиком |
| Вход и клиенты | 5 | отличить одного от другого, ничего больше |
| Оплата | 6 | платёжный провайдер, вебхук, продление |
| Лендинг и текст | 8 | четыре блока и цена, текст пишется дольше вёрстки |
| Деплой и домен | 5 | сервер, сертификат, почта, логи |
| Запас | 6 | чужой API повёл себя не по документации |
Два наблюдения из этой таблицы. Во-первых, на код уходит меньше половины бюджета — остальное инфраструктура и текст. Во-вторых, запас нужен всегда и всегда съедается: не бывает первой версии, где чужая документация совпала с реальностью.
Что режем всегда
Список короткий и почти не меняется от продукта к продукту:
- Роли и права. В первой версии клиент один и он же администратор.
- Админка. Пока клиентов меньше двадцати, их заводят руками, запросом в базу. Интерфейс для себя — это часы, которые не увидит ни один платящий.
- Настройки. Каждая галочка — это ветка в коде и вопрос в поддержку. Значение выбирается один раз, в коде, и меняется когда за это попросят.
- Восстановление пароля. Не нужно, если нет пароля: вход по ссылке из письма закрывает задачу и убирает целую подсистему.
- Мобильное приложение. Адаптивной вёрстки хватает на годы.
- Онбординг, туры по интерфейсу, пустые состояния с картинками. Первым двадцати клиентам вы объясняете продукт лично, письмом. Это не потеря, а источник половины правок.
- Личный кабинет со статистикой. Если статистика не является продуктом, её просят реже, чем кажется.
- Интеграции «на будущее». Одна, та, которую назвали в разговорах.
Общее правило простое: всё, что не участвует в цепочке «человек пришёл — понял — заплатил — получил результат», из первой версии выпадает.
Что остаётся
- Основная функция, работающая на настоящих данных клиента, а не на демо.
- Способ отличить одного клиента от другого.
- Приём денег с первого дня и понятное продление подписки.
- Лендинг: чья задача, как она решается сейчас, что делает сервис, цена.
- Почта для поддержки, которую вы читаете.
- Логи, по которым вы ночью поймёте, что именно сломалось.
Последний пункт режут чаще всего, и зря. Продукт без логов чинится гаданием, а чинить его будете вы — это не меняется от того, кто написал код: вы сами или языковая модель.
В каком порядке собирать
Порядок важнее скорости: он решает, что вы успеете, если бюджет кончится раньше продукта.
Первой делается основная функция, и сразу на настоящих данных клиента. Демо- данные всегда работают, а реальная выгрузка приходит с пустыми полями, лишними колонками и датами в трёх форматах. Узнать об этом лучше на пятом часу, чем на сороковом.
Вторым — лендинг с ценой, ещё до оплаты и деплоя. Текст, который вы напишете на этом шаге, заодно проверяет саму идею: если продукт не описывается четырьмя блоками, он не описан и у вас в голове.
Третьей — оплата, четвёртым — деплой. Если часы закончились на этом месте, у вас есть работающая функция и страница с ценой: этого достаточно, чтобы взять предоплату руками и доделать остальное на чужие деньги.
Что точно не идёт первым: выбор технологий, схема базы «на вырост» и репозиторий с настроенным CI. Это приятная работа, она создаёт ощущение движения и не приближает ни одного платежа.
Как понять, что вы не помещаетесь
Три признака, каждый из них виден на второй неделе:
Первый — вы пишете инфраструктуру, а не продукт. Своя очередь задач, своя система прав, свой слой абстракции над базой «чтобы потом поменять». Потом не наступит: половина продуктов закроется после проверки спроса.
Второй — в описании продукта появилось слово «и». «Собирает отчёты и следит за ценами и рассылает уведомления» — это три продукта, каждый из которых не доделан.
Третий — вы не можете назвать один сценарий, который клиент проходит целиком. Если сценариев три и все на половину — до оплаты не дойдёт ни один.
Лечение одно: резать охват, а не качество. Меньше сценариев, одна интеграция, один тип клиента — но то, что осталось, доведено до конца. Наполовину работающая функция хуже отсутствующей: отсутствующую человек не заметит, а сломанную запомнит.
Пятьдесят часов — не про «тяп-ляп»
Ограничение бюджета касается охвата, а не аккуратности. Что не режется никогда:
- проверка входных данных там, где данные приходят снаружи;
- обработка ошибок оплаты — деньги списались, доступ не выдался, это худший сценарий из всех;
- бэкап базы, хотя бы ежедневный дамп в объектное хранилище;
- HTTPS и нормальное хранение секретов.
Всё это вместе — несколько часов, они уже в таблице выше. Экономия на них стоит дороже, чем любая срезанная функция, и стоит она репутацией у первых двадцати клиентов, то есть у тех самых, кто приносит первые деньги.
Чек-лист готовности к запуску
- Клиент проходит сценарий от лендинга до результата, ни разу не написав мне.
- Деньги списываются, доступ выдаётся автоматически, продление работает.
- При ошибке оплаты я узнаю об этом раньше клиента.
- Есть лог, по которому видно, что делал конкретный клиент.
- База копируется каждый день.
- На лендинге названа цена. Не «по запросу».
- Я могу объяснить продукт в трёх предложениях без слова «и».
- Всё, что я хотел добавить и не добавил, записано в отдельный список.
Восемь из восьми — запуск. Не хватает первых трёх — это не запуск, а демо.
Что дальше
После запуска бюджет меняет назначение: часы уходят не на функции, а на первых клиентов и на правки по их письмам. Сколько это стоит деньгами — в смете расходов на год. Как устроена приёмка платежей в России — в отдельном разборе.
Что получается у меня и за какие сроки — в заметках и на странице проектов.
Если у вас есть задача на пятьдесят часов, которую вы решаете руками каждую неделю, — напишите в телеграм. Разберём, что в ней первая версия, а что уже вторая.
Частые вопросы
Почему именно пятьдесят часов, а не сто?
Это бюджет вечеров и выходных: десять-двенадцать часов в неделю дают около пятисот часов в год. Пятьдесят часов на попытку — это десять-двенадцать попыток за год вместо одной большой. Цифра взята из этого расчёта, а не из свойств продукта.
Что делать, если продукт не помещается в пятьдесят часов?
Резать не качество, а охват: меньше сценариев, одна интеграция вместо трёх, один тип пользователя. Если после этого не помещается — задача не для первой версии, она идёт в список следующих.
Нужна ли регистрация в первой версии?
Нужен способ отличить одного клиента от другого, но не обязательно классическая регистрация. Вход по ссылке из письма закрывает задачу и не тянет за собой восстановление пароля, подтверждение почты и форму смены пароля.
Можно ли запускать без оплаты, а деньги подключить потом?
Можно, но тогда вы не узнаете главного. Бесплатный доступ отвечает на вопрос «интересно ли», а не «готовы ли платить». Платёжная форма — это и есть проверка, ради которой всё собиралось.
Сколько из пятидесяти часов уходит на код?
У меня около половины. Вторая половина — платёжка, деплой, домен, письма, лендинг и текст на нём. Это регулярно недооценивают: в голове продукт состоит из кода, в календаре — нет.