MVP без переделки с нуля: где стартапу можно экономить, а где нельзя

Автор: Владимир Белозеров, заместитель коммерческого директора KODE

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

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

Анализ CB Insights показывает, что проблемы самого продукта остаются среди системных причин провала стартапов наряду с отсутствием product-market fit. И техническая часть здесь тесно связана с продуктовой: плохая архитектура становится особенно заметной именно тогда, когда гипотеза неожиданно сработала и продукт начал расти.

Сначала определите, зачем вам вообще нужен MVP

MVP может решать очень разные задачи, и от этого зависит глубина разработки. Если стартапу нужно проверить спрос, полноценное приложение иногда вообще не требуется.

Представим сервис доставки наборов здорового питания. Чтобы понять, готовы ли люди покупать продукт, можно запустить лендинг, подключить оплату, вести клиентов в CRM, а часть операций первое время выполнять вручную. Личного кабинета, истории заказов и отдельного мобильного приложения пока может не быть. Если люди не покупают продукт, команда сэкономила месяцы разработки. Если покупают, то появляется основание автоматизировать следующий участок.

Другое дело, когда MVP нужен для полноценного выхода на рынок. Тогда основной пользовательский сценарий уже должен работать стабильно: человек выбирает продукт, платит и получает результат без постоянной помощи команды.
А если первая версия нужна ещё и для привлечения инвестиций, требования становятся выше. Для B2B-продукта инвестору может быть важно, насколько легко подключать новых клиентов, разделены ли их данные, есть ли API, как устроены роли и можно ли масштабировать систему без полной переделки.
Поэтому сначала нужен ответ на вопрос: что именно должна доказать эта версия продукта?

На интерфейсе можно сэкономить. На фундаменте — осторожнее

У MVP совершенно нормально может не быть красивой анимации, десяти типов отчётов или сложной системы персонализации. Это не мешает проверить гипотезу. Гораздо опаснее упрощать то, от чего зависит дальнейшее развитие продукта.

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

В момент запуска всё это может работать прекрасно. Проблемы появляются когда продукт приходится менять. Поэтому перед разработкой полезно разделить будущие решения на две группы. Что мы сознательно делаем временно? Например, ручное формирование отчёта вместо автоматического или простую админку вместо полноценного интерфейса. И: что будет слишком дорого поменять потом? Сюда обычно попадают данные, ключевая архитектура, авторизация, безопасность, основные интеграции и инфраструктура.Это и есть настоящая граница разумной экономии на MVP.

Но строить систему сразу на миллион пользователей тоже не нужно

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

Допустим, сейчас у продукта 500 пользователей, а после запуска рекламной кампании команда рассчитывает получить несколько тысяч. Тогда стоит заранее понимать:

1. выдержит ли система такую нагрузку;
2. где появятся узкие места;
3. можно ли увеличить ресурсы без переписывания продукта;
4. какие компоненты сложнее всего масштабировать.

То есть не обязательно строить идеальную архитектуру навсегда. Но у команды должен существовать понятный путь от первой версии ко второй.

Самый дешёвый подрядчик может оказаться самым дорогим

Цена разработки важна для стартапа. Но сравнивать подрядчиков только по итоговой сумме предложения опасно. Представим две команды. Первая получает ТЗ и сразу оценивает разработку. Вторая начинает задавать вопросы: «Зачем вам эта функция?», «Какую гипотезу она проверяет?», «Почему пользователь должен делать это именно таким способом?», «Что произойдёт, если на первом этапе мы её вообще не сделаем?»
Со стороны может показаться, что вторая команда просто усложняет процесс. Но именно такие вопросы нередко позволяют выбросить из первой версии значительную часть функций. Допустим, стартап создаёт сервис бронирования экскурсий и просит разработать личный кабинет, чат, оплату, уведомления и несколько сценариев управления заказом. Всё это можно сделать точно по ТЗ.

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

Критерии успеха лучше определить до первой строчки кода

У MVP есть ещё одна неприятная особенность: после запуска почти всегда можно найти цифру, которая выглядит хорошо. Нет оплат? Зато много регистраций. Мало регистраций? Зато высокий трафик. Люди не возвращаются? Зато скачали приложение несколько тысяч раз. Чтобы не подгонять вывод под результат, метрики лучше определить до старта. Если задача MVP в том, чтобы проверить спрос, можно смотреть на:

1. конверсию в целевое действие или оплату;
2. стоимость привлечения;
3. повторное использование;
4. качественную обратную связь.

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

Некоторые вещи нельзя оставить «на потом»

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

1. кому принадлежит исходный код;
2. где хранится репозиторий;
3. на кого оформлены домены и облачные аккаунты;
4. кто имеет доступ к инфраструктуре;
5. что произойдёт с кодом и документацией после окончания договора.

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

Смотрите не только на стоимость MVP, но и на цену следующей функции

Предположим, две компании предлагают разработать продукт за 3 и 4 млн рублей. Кажется, что разница — миллион. Но через полгода в первый продукт нужно добавить новую интеграцию. Старую архитектуру приходится частично переделывать, и доработка стоит ещё 1,5 млн. Во втором случае новая интеграция подключается значительно проще. И первоначальная разница в стоимости быстро исчезает. Поэтому полезно считать не только цену создания первой версии, но и хотя бы приблизительную стоимость владения:

1. инфраструктуру;
2. тестирование;
3. поддержку;
4. исправление ошибок;
5. обновления;
6. будущие интеграции;
7. масштабирование.

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

Красные флаги до начала разработки

Некоторые проблемы можно заметить ещё на переговорах. Стоит насторожиться, если подрядчик после короткого созвона обещает точную стоимость и дату запуска, почти ничего не спросив про аудиторию, бизнес-модель и дальнейшие планы продукта. Ещё один сигнал — команда не может объяснить, какие технические решения сейчас временные, а какие закладываются надолго. И третий — разработчики не хотят обсуждать документацию, права на код и передачу проекта. Это не означает, что подрядчик обязательно плохой. Но стартапу стоит заранее понимать, что произойдёт, если через полгода понадобится сменить команду или пройти технический аудит.

Десять вопросов перед стартом MVP

До начала разработки полезно проверить себя:

1. Какую одну основную гипотезу проверяет первая версия?
2. Можно ли проверить её без полноценной разработки?
3. Какие функции нужны для главного пользовательского сценария?
4. Что на первом этапе можно делать вручную?
5. Какие технические решения мы сознательно считаем временными?
6. Какие части системы потом будет особенно дорого переделать?
7. Как продукт должен выдержать ближайший реалистичный рост?
8. Кто владеет кодом, данными, инфраструктурой и аккаунтами?
9. Какие показатели покажут, что MVP сработал?
10. Что придётся сделать технически, если гипотеза подтвердится и продукт начнёт расти?

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

MVP должен помогать ошибаться дёшево

Первая версия не должна быть идеальной. Наоборот, смысл MVP в том, чтобы как можно раньше выяснить, где команда ошиблась: в аудитории, функции, цене, сценарии использования или самой гипотезе. Поэтому часть решений вполне можно делать временными. Но важно понимать, какими именно. Ручной процесс вместо автоматизации — нормально. Минимальный интерфейс вместо идеального дизайна — нормально. Одна основная функция вместо двадцати — нормально.
А вот продукт, который при первом росте приходится полностью переписывать, уже сложно назвать экономией. Хороший MVP не пытается предсказать всё будущее стартапа. Он просто оставляет возможность это будущее построить.