The 'reversible decision' framing from Bezos-style thinking is often misapplied in software engineering. A two-way door decision is not a static property — it's an option whose exercise price rises every time another team, dashboard, or system builds on top of the chosen tool. Using feature flags, cloud services, CI/CD, and observability as examples, the post argues that reversibility must be actively maintained, not assumed. Practical advice includes naming reversibility assumptions in ADRs, periodically re-pricing the exit cost, testing the exit path, and consciously letting low-value options expire when the maintenance cost outweighs the benefit.
Table of contents
Choices often go beyond code.Reversibility is an option; options have a priceOptionality is maintained, not ownedThis applies everywhereWhat to do instead?ConclusionQuestions this post answers
Why does a 'reversible' technical decision become harder to undo over time?
A reversible decision is an option whose exercise price rises every time another team or system builds on top of the chosen tool. What starts as a simple feature flag swap becomes expensive when product teams use it as a feature gate, data science uses it for A/B testing, and dashboards read from its API. The code change stays simple, but the system-wide migration grows far more complex. Engineers weighing vendor lock-in trade-offs track how these costs compound on daily.dev.
What should I include in an ADR to preserve the reversibility of a technical decision?
State explicitly what conditions make the decision reversible. For example, if adopting a feature flag provider, document a rule like 'no service may read flag state directly' — this is a deliberate constraint that preserves the exit option at the cost of some convenience. Also assign a rough exit-cost estimate and a direction of travel, then revisit it periodically rather than treating it as a one-time assessment. Teams writing ADRs for infrastructure choices find related architectural thinking on daily.dev.