Most Decisions Are Cheaper to Reverse Than They Feel
Framework choice, folder structure, which state management library — these feel consequential in the room and are, in practice, a few days of migration work later if they're wrong. Teams routinely spend weeks debating decisions in this category and hours on the ones that actually matter. The imbalance is the problem, not the debate itself.
The Real Irreversibles Live at the Boundaries
Where data lives and who owns writing to it. What a service is allowed to know about another service. The shape of a public API once external clients depend on it. The identity model, once accounts and permissions are built against it. These decisions are expensive to reverse because reversing them means migrating live data, coordinating multiple teams, or breaking someone else's integration — not rewriting a module.
None of these announce themselves as irreversible at decision time. They just accumulate dependents faster than anything else in the system.
Cost to Reverse Is a Better Filter Than Perceived Importance
"How senior does this decision feel" is a weak prioritisation signal — it tracks confidence, not consequence. "What does it cost, in time and risk, to change this after six months of data has been written against it" is a much sharper one. Run new architecture decisions through that question specifically, not a general sense of how big the decision feels.
Write the Assumption Down, Not Just the Decision
A decision record that says what was chosen is half the value. The half that matters later is what was assumed to be true when it was chosen — expected scale, expected access patterns, expected team size. When the assumption breaks, that's the signal to revisit the decision. Without it, nobody can tell whether the original reasoning still holds or whether the decision is just old.