Speed matters most when you are searching for product-market fit, so early architecture should be simple and cheap to change. The trap is that the MVP that wins does not get rewritten — it gets extended, under pressure, by a growing team. The decisions you made to move fast become the constraints you live with. The goal is not to over-engineer early; it is to make the cheap-now decisions that stay cheap later.
Optimise for change, not for scale
You almost never know which part of the product will need to scale, so do not pay upfront for scale you may never need. Pay instead for changeability: clear module boundaries, a schema you can migrate, and the discipline to keep business logic out of the framework. A codebase that is easy to change can be scaled when the need is real; a prematurely "scalable" one is often just hard to move.
The decisions that are expensive to reverse
- Your data model — migrations get harder with every row and every integration.
- Authentication and tenancy — retrofitting multi-tenancy or proper auth is painful.
- Public API contracts — once clients depend on them, you cannot freely change them.
- Where state lives — moving it later touches everything that reads it.
Keep the rest boring and replaceable
For everything that is not expensive to reverse, choose boring, well-understood technology and keep it behind clean boundaries so it can be swapped. The art of an MVP that becomes a foundation is knowing the short list of decisions worth getting right early — and deliberately under-investing in everything else until the product tells you where to spend.
Built this way, your first version is not technical debt. It is the smallest thing that can grow up.