У нас в команде работает такой принцип: MVP пишем как "модульный монолит" — один сервис, но с чёткими границами между доменами внутри. Clean Architecture с самого старта, даже если это один процесс.

Когда приходит нагрузка или появляется второй сервис — модули уже готовы к выделению, контракты описаны, зависимости явные. Это дешевле чем sqlite→postgres миграция под давлением продакшена.

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

Артем, в компании держим баланс так: сначала быстро проверяем гипотезы и технологии в пилотах, а уже потом масштабируем только те решения, которые доказали ценность. Доказанное решение дальше встраиваем в общую инфру и обеспечиваем готовность к нагрузке, безопасность, подключение к общим процессам. Большое enterprise-решение никогда не случается одномоментно.

у нас развязка такая: mvp максимально простой - sqlite + fastapi, минимум зависимостей. как только появляются реальные нагрузки или второй сервис - переходим на postgres + docker + очереди. боль начинается когда mvp-код не рассчитан на замену - тогда scale == переписать.