Shipping an MVP in Weeks Without Painting Yourself Into a Corner
Speed and maintainability are not opposites. The decisions that keep an MVP extendable.
An MVP exists to learn quickly, but the code you write for it rarely disappears. The goal is to move fast on the things that are cheap to change and to be deliberate about the few that are not.
Cheap to change: interface details, copy, most feature logic. Expensive to change: your data model, authentication, multi-tenancy and the boundaries between services. Spend design time on the second list.
Use boring, well-supported technology. A typed codebase, a relational database and a managed platform remove whole categories of problems that slow a young product down.
Ship to real users early, instrument what they do, and plan the second iteration around evidence rather than the original backlog.