Архитектура

Быстрый MVP не обязан быть одноразовым

Первая версия должна запускаться быстро. Она не должна закладывать решения, которые придётся выбрасывать вместе с данными.

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

Что можно упростить, а что нельзя

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

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

Скорость без сюрприза

Хороший первый релиз узкий, но честный: понятно, что он умеет, чего не умеет и какой следующий этап не сломает уже записанные данные.