Every architecture is a bet on the future. The trouble is that early in a product's life, the future is the thing you know least about. Choosing a complex, distributed design up front means paying its costs today for benefits you may never need.
Our default is intentionally unexciting: a well-structured modular application, a relational database, clear boundaries and good tests. It is the architecture most likely to still make sense in three years — and the easiest to evolve when it doesn't.
Boundaries matter more than deployment units
The real value of microservices is not that they deploy separately; it is that they force clear boundaries between parts of a system. You can have those boundaries without a network in between.
- Organise code by business capability — billing, scheduling, inventory — not by technical layer.
- Let modules talk through explicit interfaces, never through each other's tables.
- Enforce the rules with tooling so the structure survives deadlines.
A modular application built this way can be split later along lines that already exist, rather than lines guessed at on day one.
Choose technology with a long half-life
Mature languages, frameworks and databases come with documentation, security patches, a deep hiring pool and answers to strange production problems. New tools earn their place when they solve a problem the mature options genuinely can't.
Spend innovation where it creates value for customers — not on infrastructure they will never see.
Know what would make you change
Boring is a starting point, not a principle to defend forever. We write down the signals that would justify more complexity: a component that needs to scale independently, a team that needs to deploy without coordinating, a workload with genuinely different reliability needs.
When those signals appear, the move is a targeted extraction — one well-understood boundary at a time — rather than a rewrite.
Make it easy to change
The best predictor of a system's future isn't its architecture diagram; it's how safely it can be changed. Typed code, automated tests at the right levels, reproducible environments and a fast delivery pipeline are what keep any architecture adaptable.