SkobarevЗаметкиБаза знанийПроектыОбо мнеRead in English

MVP за 50 часов: что входит, а что режем

#MVP#micro SaaS

Пятьдесят часов — это не лозунг про скорость, а бюджет. Вечера и выходные дают десять-двенадцать часов в неделю, за год выходит около пятисот пятидесяти. Разделите их на двенадцать попыток — получите пятьдесят на продукт, включая лендинг, оплату и деплой.

Из этого следует всё остальное. Пятьдесят часов — не цель, а ограничение, которое решает, что в продукт войдёт.

Куда уходят пятьдесят часов

Моя раскладка, по опыту первых сборок:

Блок Часы Что сюда входит
Основная функция 20 то, ради чего платят, целиком
Вход и клиенты 5 отличить одного от другого, ничего больше
Оплата 6 платёжный провайдер, вебхук, продление
Лендинг и текст 8 четыре блока и цена, текст пишется дольше вёрстки
Деплой и домен 5 сервер, сертификат, почта, логи
Запас 6 чужой API повёл себя не по документации

Два наблюдения из этой таблицы. Во-первых, на код уходит меньше половины бюджета — остальное инфраструктура и текст. Во-вторых, запас нужен всегда и всегда съедается: не бывает первой версии, где чужая документация совпала с реальностью.

Что режем всегда

Список короткий и почти не меняется от продукта к продукту:

  • Роли и права. В первой версии клиент один и он же администратор.
  • Админка. Пока клиентов меньше двадцати, их заводят руками, запросом в базу. Интерфейс для себя — это часы, которые не увидит ни один платящий.
  • Настройки. Каждая галочка — это ветка в коде и вопрос в поддержку. Значение выбирается один раз, в коде, и меняется когда за это попросят.
  • Восстановление пароля. Не нужно, если нет пароля: вход по ссылке из письма закрывает задачу и убирает целую подсистему.
  • Мобильное приложение. Адаптивной вёрстки хватает на годы.
  • Онбординг, туры по интерфейсу, пустые состояния с картинками. Первым двадцати клиентам вы объясняете продукт лично, письмом. Это не потеря, а источник половины правок.
  • Личный кабинет со статистикой. Если статистика не является продуктом, её просят реже, чем кажется.
  • Интеграции «на будущее». Одна, та, которую назвали в разговорах.

Общее правило простое: всё, что не участвует в цепочке «человек пришёл — понял — заплатил — получил результат», из первой версии выпадает.

Что остаётся

  • Основная функция, работающая на настоящих данных клиента, а не на демо.
  • Способ отличить одного клиента от другого.
  • Приём денег с первого дня и понятное продление подписки.
  • Лендинг: чья задача, как она решается сейчас, что делает сервис, цена.
  • Почта для поддержки, которую вы читаете.
  • Логи, по которым вы ночью поймёте, что именно сломалось.

Последний пункт режут чаще всего, и зря. Продукт без логов чинится гаданием, а чинить его будете вы — это не меняется от того, кто написал код: вы сами или языковая модель.

В каком порядке собирать

Порядок важнее скорости: он решает, что вы успеете, если бюджет кончится раньше продукта.

Первой делается основная функция, и сразу на настоящих данных клиента. Демо- данные всегда работают, а реальная выгрузка приходит с пустыми полями, лишними колонками и датами в трёх форматах. Узнать об этом лучше на пятом часу, чем на сороковом.

Вторым — лендинг с ценой, ещё до оплаты и деплоя. Текст, который вы напишете на этом шаге, заодно проверяет саму идею: если продукт не описывается четырьмя блоками, он не описан и у вас в голове.

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

Что точно не идёт первым: выбор технологий, схема базы «на вырост» и репозиторий с настроенным CI. Это приятная работа, она создаёт ощущение движения и не приближает ни одного платежа.

Как понять, что вы не помещаетесь

Три признака, каждый из них виден на второй неделе:

Первый — вы пишете инфраструктуру, а не продукт. Своя очередь задач, своя система прав, свой слой абстракции над базой «чтобы потом поменять». Потом не наступит: половина продуктов закроется после проверки спроса.

Второй — в описании продукта появилось слово «и». «Собирает отчёты и следит за ценами и рассылает уведомления» — это три продукта, каждый из которых не доделан.

Третий — вы не можете назвать один сценарий, который клиент проходит целиком. Если сценариев три и все на половину — до оплаты не дойдёт ни один.

Лечение одно: резать охват, а не качество. Меньше сценариев, одна интеграция, один тип клиента — но то, что осталось, доведено до конца. Наполовину работающая функция хуже отсутствующей: отсутствующую человек не заметит, а сломанную запомнит.

Пятьдесят часов — не про «тяп-ляп»

Ограничение бюджета касается охвата, а не аккуратности. Что не режется никогда:

  • проверка входных данных там, где данные приходят снаружи;
  • обработка ошибок оплаты — деньги списались, доступ не выдался, это худший сценарий из всех;
  • бэкап базы, хотя бы ежедневный дамп в объектное хранилище;
  • HTTPS и нормальное хранение секретов.

Всё это вместе — несколько часов, они уже в таблице выше. Экономия на них стоит дороже, чем любая срезанная функция, и стоит она репутацией у первых двадцати клиентов, то есть у тех самых, кто приносит первые деньги.

Чек-лист готовности к запуску

  1. Клиент проходит сценарий от лендинга до результата, ни разу не написав мне.
  2. Деньги списываются, доступ выдаётся автоматически, продление работает.
  3. При ошибке оплаты я узнаю об этом раньше клиента.
  4. Есть лог, по которому видно, что делал конкретный клиент.
  5. База копируется каждый день.
  6. На лендинге названа цена. Не «по запросу».
  7. Я могу объяснить продукт в трёх предложениях без слова «и».
  8. Всё, что я хотел добавить и не добавил, записано в отдельный список.

Восемь из восьми — запуск. Не хватает первых трёх — это не запуск, а демо.

Что дальше

После запуска бюджет меняет назначение: часы уходят не на функции, а на первых клиентов и на правки по их письмам. Сколько это стоит деньгами — в смете расходов на год. Как устроена приёмка платежей в России — в отдельном разборе.

Что получается у меня и за какие сроки — в заметках и на странице проектов.

Если у вас есть задача на пятьдесят часов, которую вы решаете руками каждую неделю, — напишите в телеграм. Разберём, что в ней первая версия, а что уже вторая.

Частые вопросы

Почему именно пятьдесят часов, а не сто?

Это бюджет вечеров и выходных: десять-двенадцать часов в неделю дают около пятисот часов в год. Пятьдесят часов на попытку — это десять-двенадцать попыток за год вместо одной большой. Цифра взята из этого расчёта, а не из свойств продукта.

Что делать, если продукт не помещается в пятьдесят часов?

Резать не качество, а охват: меньше сценариев, одна интеграция вместо трёх, один тип пользователя. Если после этого не помещается — задача не для первой версии, она идёт в список следующих.

Нужна ли регистрация в первой версии?

Нужен способ отличить одного клиента от другого, но не обязательно классическая регистрация. Вход по ссылке из письма закрывает задачу и не тянет за собой восстановление пароля, подтверждение почты и форму смены пароля.

Можно ли запускать без оплаты, а деньги подключить потом?

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

Сколько из пятидесяти часов уходит на код?

У меня около половины. Вторая половина — платёжка, деплой, домен, письма, лендинг и текст на нём. Это регулярно недооценивают: в голове продукт состоит из кода, в календаре — нет.

← База знаний