Across different companies, stages, and stacks, I keep seeing the same pattern.
Most of the problems weren't caused by wrong decisions. They were caused by right decisions made in the wrong order.
What sequencing problems look like
A common version is a team investing in infrastructure before the product is stable. They build the pipeline, microservices, and observability stack before they know what they're scaling. Then the product changes and the architecture becomes a constraint.
Or the reverse: a team moves fast, ships a monolith, gets traction, and realises its early decisions are now load-bearing walls. The right decomposition is obvious in retrospect, but each next step is harder.
Neither team made bad decisions at the time. They both made reasonable calls. The problem is that the calls were made in the wrong order relative to what they actually knew and needed.
Why sequence matters more than the decision itself
Most technology decisions are reversible. The cost depends on what you've built on top.
A choice of database engine is reversible. If you've built three hundred service integrations that depend on Postgres-specific behaviour, the reversal cost is enormous. If you've been running for six months and have one service talking to it, you can migrate over a weekend.
The decision is the same. The sequence is different.
That is why I'm often more interested in what a team did before a decision. "Should we build microservices?" is almost impossible to answer without the team size, deployment frequency, domain complexity, and the next few things on the roadmap. Sequence changes the answer.
Where sequencing goes wrong
Solving scale before you have load: Building distributed systems, caches, and horizontal scaling before traffic justifies them. The engineering is interesting, but it solves a future problem at the expense of understanding the product today.
Standardising before you have variety: Introducing frameworks and shared libraries before you know which patterns repeat and which are accidents of the moment.
Modernising the wrong layer first: Legacy migrations often start with the most interesting part instead of the biggest constraint. I've seen teams rebuild a data pipeline before stabilising the domain model, or redesign an API before understanding the service beneath it. They then revise the new layer again.
Abstracting the team too early: Hiring around a future architecture, forming a platform team before its purpose is clear, or creating specialist roles before the work needs them.
What good sequencing looks like
There is no correct order for every situation. The aim is to make each decision with enough information while keeping the cost of being wrong low.
A few questions help:
If this decision turns out to be wrong, what's the cheapest way to recover, and what would I need to preserve to do that? This is the classic reversibility framing, but applied to what comes after rather than the decision itself.
What has to be true about the current layer before this layer can be addressed well? Often a problem at one layer is actually a symptom of something unsettled in the layer below it. Fixing the symptom is faster but might not stay fixed.
Is this based on current evidence or a future state that may not happen? Sometimes you have to build ahead. It should be a conscious choice, not the default.
This isn't a formula. The same analysis can produce different answers in different contexts. Still, asking when often reveals options that a discussion about what would miss.
If you're working through a technology decision, I'm happy to compare notes.