5 ошибок при запуске MVP, которые дорого обходятся потом
MVP — это не «сделать плохо, чтобы сделать быстро». Это выбор: что оставить, а что отложить. Проблема в том, что некоторые «отложенные» решения потом нельзя добавить без переделки половины системы. Вот пять таких ловушек.
1. Не думать про авторизацию заранее
«Пока один клиент, права не нужны» — звучит разумно. Но как только появляется второй — оказывается, что авторизация пронизывает всю систему: запросы к базе, API-методы, логику уведомлений. Добавить её потом означает переписать почти всё.
Минимум, который стоит заложить сразу: модель пользователя, ownership записей и базовое разграничение ролей. Не нужна сложная RBAC — достаточно скелета, в который можно добавить детали.
2. Хардкодить бизнес-правила прямо в код
Комиссия 10%, срок обработки 3 дня, максимальный размер файла 5 МБ — если это числа в коде, первое же изменение требует деплоя. Бизнес-правила меняются — это их природа.
Выносите настраиваемые параметры в конфиг или в базу. Это займёт на час дольше при разработке, но сэкономит дни при каждом следующем изменении.
3. Монолитная структура, которую невозможно разделить
MVP необязательно должен быть микросервисным — но код стоит организовать так, чтобы модули можно было разделить при необходимости. Если логика заказов, уведомлений и биллинга перемешана в одном месте — любое изменение рискует задеть всё остальное.
Не нужна идеальная архитектура с первого дня. Нужна достаточно чёткая граница между доменами: отдельные модули, сервисы или хотя бы папки с понятной ответственностью.
4. Игнорировать структуру данных
Схема базы данных — это один из самых дорогих в изменении артефактов. Добавить колонку просто, удалить или переименовать — сложно, изменить тип данных — больно. Потратьте время на её проектирование до первой миграции.
Типичные промахи: хранить несколько значений в одном поле через запятую, использовать строки там, где нужны числа, игнорировать индексы. Всё это работает на маленьком объёме и ломается при росте.
- Нормализуйте данные — не дублируйте то, что можно получить JOIN-ом
- Добавляйте индексы для полей, по которым часто фильтруете
- Не храните состояние как строку — используйте enum или отдельную таблицу
- Продумайте soft delete сразу, если удалённые данные могут понадобиться
5. Не считать стоимость масштабирования
Синхронная обработка файлов в HTTP-запросе, email напрямую в контроллере, тяжёлые запросы без кеша — всё это незаметно при 10 пользователях и превращается в проблему при 1000.
Не нужно сразу строить инфраструктуру для миллиона пользователей. Но стоит знать, где у вашей системы узкие места, и оставить возможность добавить очередь, кеш или CDN без переписывания логики.