MVP — это не уменьшенная версия всего. Это полная версия одного.
Это различие определяет, выйдет ли первый релиз за месяцы или будет тянуться год. Но есть второе различие, не менее важное: часть решений потом изменить дёшево, а три — нет.
Три решения, которые дёшево не откатить
Модель мультиарендности. Общая схема с колонкой арендатора, отдельная схема на арендатора или отдельная база. У каждого варианта реальные последствия для изоляции, стоимости, гранулярности резервных копий, соответствия требованиям и сложности запросов. Менять это потом — почти переписывание, потому что на выбранной модели завязаны все запросы, миграции и процедуры бэкапа.
Модель прав. Не «роли добавим потом». Привязаны ли права к пользователю, к членству или к ресурсу; может ли организация содержать команды; может ли пользователь состоять в нескольких организациях. Встроить настоящую модель прав в продукт, построенный на if (user.isAdmin), — значит переписать каждый эндпоинт.
Ключевые связи модели данных. Конкретно: что кому принадлежит. Если документ принадлежит пользователю, а потом должен принадлежать организации, это затрагивает все ссылки, все проверки доступа и все миграции.
Всё остальное — интерфейс, набор функций, тарифы, онбординг и даже фреймворк — можно поменять позже за разумные деньги. Эти три — нет.
Сначала стройте скучный слой
Интересная часть продукта — та, что решает задачу клиента. Часть, которая позволяет его продавать, — это аутентификация, организации, роли, приглашения, биллинг, лимиты и админка.
Команды делают сначала интересную часть, успешно её показывают, а потом обнаруживают, что вывести её на второго клиента — это два месяца неблагодарной работы, которую никто не закладывал.
Начинайте со скучного слоя. Это действительно менее увлекательно — и именно это отличает продукт от прототипа.
Отдельно стоит сказать про админку, потому что её пропускают чаще всего. Без входа от имени пользователя, журнала действий, просмотра использования и безопасных ручных операций ваш процесс поддержки превращается в «разработчик открывает боевую базу». Это одновременно проблема безопасности, доступности и масштабирования, и с каждым новым клиентом она усугубляется.
Что на самом деле значит «минимальная продаваемая версия»
Критерий не «хорошо ли это будет смотреться на демо», а: сможет ли реальный клиент пользоваться этим в проде и сможете ли вы без стыда выставить ему счёт?
Такая переформулировка обычно сильно режет объём. И обычно она же добавляет пару вещей, которые команда хотела отложить: клиент, который не может сам сбросить пароль, добавить коллегу или увидеть, за что с него берут деньги, — это не тот клиент, которому можно выставить счёт.
Полезное упражнение: опишите по шагам, как новый клиент проходит онбординг без участия разработчика ни на одном шаге. Всё, что нужно для этой последовательности, входит в объём. Всё остальное обсуждаемо.
Размечайте с первого клиента
Активация, использование и сигналы оттока должны существовать с первого дня. Прикручивать аналитику после запуска — значит потерять самые ранние и самые информативные данные: как на самом деле вели себя ваши первые десять клиентов.
Минимум: что аккаунт сделал в первой сессии, что — за первую неделю и какие аккаунты перестали делать что-либо. Три вопроса, на которые можно отвечать с самого начала, стоят больше, чем сложный дашборд, появившийся на шестой месяц.
Записывайте, что вы отложили
Каждое отложенное архитектурное решение стоит зафиксировать двумя строками: что отложили и во что обойдётся возврат.
Этот документ — самый ценный артефакт, который вы передадите тому, кто будет поддерживать продукт дальше, включая вас самих через полгода. Код показывает, что построено. Он никогда не показывает, что рассматривали и отвергли, почему и при каком ограничении. Через полгода именно этот контекст отличает уверенное изменение от археологических раскопок.
И будьте готовы узнать, что вы ошиблись
Смысл маленькой первой версии — дёшево научиться. Если продукт никому не нужен, MVP покажет это за месяцы, а не после полутора лет работы над платформой.
Это успешный исход, а не провальный, хотя в моменте так почти никогда не ощущается. Провал — это построить полную платформу и узнать то же самое позже, потратив в десять раз больше.