Most teams I’ve worked with default to the most powerful tool available, not the simplest one that solves the problem. State machines for forms with two fields. Microfrontends for products with three engineers. Custom build pipelines for sites with five pages.
Complexity should be earned, not assumed. A pattern is justified when:
- the problem it solves is actually present in the system today
- the cost of removing it later is bounded
- the team can articulate the tradeoff in one sentence
If you can’t say why not the simpler thing, the simpler thing is probably right.
The corollary: every architectural decision should have an expiration date in your head. “We chose X because Y is true today. When Y stops being true, we revisit.”
That’s not indecision — it’s keeping the system honest about what it actually needs.