The asymmetry that should govern process
The reversibility of a technical decision is not a property of the decision itself; it is a property of the dependencies that accumulate after you make it. A choice is cheap to reverse when nothing has been built on top of it, and nearly permanent once a large surface area of code, data, and human habit assumes it is true. The practical mechanism is the coupling gradient: every consumer of an interface, every row written in a chosen schema, every integration wired to a vendor's API converts a reversible decision into an irreversible one a little more each day. This is why the right question is rarely "is this the best technology?" but "how much will depend on this before we could plausibly change our minds, and how fast?"
The decision implication is direct. Two-way doors — choices you can walk back through at low cost — deserve speed, delegation, and a bias toward learning by shipping. One-way doors deserve deliberation, senior attention, and a willingness to spend weeks deciding. The expensive error is applying the wrong process to either: agonizing over a feature flag while approving a database engine in a hallway conversation.
How to read a door before you walk through it
The reversibility map is built from a small number of signals that predict the cost of reversal far better than intuition does. A team can score any decision against them in an hour.
- Blast radius: how many systems and teams would have to change in lockstep to undo it. A logging library touches one module; an authentication model touches everything.
- Data gravity: whether the choice accumulates state. Stateless services are two-way doors; the moment a decision writes the canonical copy of customer data, migration cost grows with every record.
- Public contract: whether the decision is exposed to parties you do not control — external API consumers, on-device clients you cannot force-update, regulators. Anything published to outsiders hardens fast.
- Exit cost shape: whether reversal is a one-time refactor or an ongoing dual-running tax. Doors that require you to operate the old and new world simultaneously are the heaviest of all.
The map is roughly continuous, but three regions matter. Genuinely reversible: framework choices, internal module boundaries, most UI. Hard to reverse but survivable: language runtime, cloud provider, the shape of your service decomposition. Effectively permanent on the timescales that matter: your primary data model, your identity and authorization model, your public API surface, and any cryptographic or privacy commitment you have made to users. Permanence is not about difficulty alone; it is difficulty multiplied by the number of outside parties who must consent to the change.
The two failure modes, and why the second is quieter
The visible failure is treating a one-way door as two-way: shipping a schema, an API, or a data-retention promise fast, then discovering that thousands of dependents have hardened it into bedrock. This failure is loud and instructive, and most engineering organizations eventually learn to slow down on data and contracts. The quieter, more corrosive failure runs the other way — treating two-way doors as one-way. When a team deliberates a reversible choice as if it were permanent, it pays a tax that never appears on any incident report: decisions that should take a day take a quarter, and the option value of fast iteration is destroyed by the very caution meant to protect it.
There is also a manufactured trap worth naming. Reversible decisions can be deliberately welded shut to create leverage — a vendor that encourages you to store canonical data in its proprietary format is converting your two-way door into a one-way door on its behalf. Recognizing this lets you preserve reversibility cheaply, by keeping the canonical copy in a format you own and treating the vendor as a replaceable consumer rather than the system of record.
Designing for the door you cannot avoid
Some one-way doors are unavoidable; the architectural move is to shrink the door rather than to deliberate longer. An anti-corruption layer turns an irreversible vendor choice into a reversible one by isolating its assumptions behind an interface you own. Versioning a public API converts a permanent contract into a sequence of survivable ones. Writing a migration path before you write the schema makes a heavy door lighter on the day you need it. The discipline is not to make every decision reversible — that is its own form of paralysis, paid in abstraction you may never use — but to spend reversibility deliberately, buying it where the map shows a one-way door and a real chance you are wrong, and declining to buy it where you are confident or where reversal would have been cheap anyway. The reversibility map's final use is as a budget: it tells you where your finite supply of deliberation, and of architectural insurance, will actually earn its cost.