The architecture decisions that are hardest to reverse
Not every decision deserves the same amount of deliberation.
Some architecture decisions are cheap to undo — swap a library, rename a service, refactor a module. Others quietly become load-bearing: your data model, your authentication approach, the boundary between services, the format you chose for something now written to by a dozen other systems. Those deserve more deliberation up front, precisely because they get more expensive to change over time.
Equal weight is the trap
The trap is treating every decision with equal weight — either agonizing over things that are trivially reversible, or rushing through the ones that aren't because the codebase is small right now and nothing feels permanent yet. Both waste the same scarce resource: attention.
Data models age the worst
Of all the decisions that harden into permanence, data models tend to age the worst — every feature built on top of a schema makes that schema harder to change, and by the time the limitation is obvious, dozens of other systems already assume it. Get the shape roughly right early, even if everything else stays flexible.
A simple test for where to spend deliberation
A useful habit is asking, before any significant decision, how expensive this would be to reverse in a year. If the answer is "an afternoon," move fast. If the answer is "a migration project," it's worth the extra hour of discussion now.
- Not every decision deserves equal deliberation — weigh by reversibility, not comfort.
- Data models and service boundaries are usually the expensive-to-reverse ones.
- Ask 'how hard would this be to undo in a year' before committing.
Why "temporary" fixes become permanent — and how to stop it
HAVE A PRODUCT IN MIND?
Tell us what you're building and where you need engineering support.