One-Way & Two-Way Doors
Jeff Bezos introduced this framework in his 2015 letter to Amazon shareholders, and it remains one of the most practical mental models for engineering decision-making. The idea is simple: some decisions are reversible (two-way doors) and some are not (one-way doors). The type of door should determine how much time and process you invest in the decision.
The Framework
A two-way door is a decision you can undo. If you walk through and do not like what you see, you walk back. The cost of reversal is low. These decisions should be made quickly, with limited analysis, by individuals or small teams.
A one-way door is a decision you cannot undo — or can only undo at enormous cost. Once you walk through, you are committed. These decisions deserve careful analysis, broad input, and deliberate process.
Two-way doors (reversible):
- Choosing a CSS framework
- Feature flag rollout strategy
- Internal API design (before external consumers exist)
- Trying a new deployment tool
- Reorganizing a team temporarily
One-way doors (irreversible or very costly to reverse):
- Public API contract
- Database schema for a live system with millions of rows
- Choosing your primary programming language
- Signing a 3-year vendor contract
- Deleting user data
The classification is not binary — it is a spectrum. But the mental exercise of asking "how reversible is this?" before investing decision-making energy fundamentally changes how teams operate.
The Real Problem: Treating Two-Way Doors as One-Way
Bezos's core observation was not that one-way doors need care — that is obvious. The insight is that most organizations treat two-way doors as one-way doors. They apply the same heavyweight decision process to every choice, regardless of reversibility. The result is slowness.
Scenario: The team needs to choose between two logging libraries.
One-way door treatment:
Write a design doc. Schedule a meeting. Invite 8 people.
Debate for an hour. Assign follow-up research. Schedule
another meeting. Debate again. Final decision in 2 weeks.
Two-way door treatment:
Pick the one with better documentation. Try it for a sprint.
If it's bad, switch. Decision in 15 minutes.
The logging library is a two-way door. If the choice is wrong,
switching costs about 2 days of work. The 2-week decision process
cost more than the worst-case outcome of choosing wrong.
This pattern is everywhere in engineering organizations. Teams spend days debating CI providers, weeks evaluating task queues, and months choosing monitoring tools — all two-way doors. The cost of the decision process routinely exceeds the cost of being wrong.
Classifying Engineering Decisions
The key skill is correctly classifying decisions before investing time in them. Here is a framework for classification:
What Makes a Decision One-Way?
A decision is one-way when reversal is impossible or the cost of reversal is extremely high relative to the stakes:
Factor Why it makes reversal costly
--- ---
External consumers depend on it Changing a public API breaks clients.
Data has been written Changing a database schema requires
migration of millions of rows.
Contracts are signed Legal and financial commitments
cannot be undone.
Trust has been spent Promising a feature publicly and
then removing it damages credibility.
Time has passed 6 months of development on the wrong
architecture is 6 months you don't
get back.
What Makes a Decision Two-Way?
A decision is two-way when reversal is cheap, quick, and does not damage anything external:
Factor Why reversal is cheap
--- ---
Internal only No external consumers to break.
Behind a feature flag Toggle off and the change disappears.
Small blast radius Only affects one team or one service.
No data migration needed Switching libraries does not require
moving data.
Low adoption cost Nobody spent weeks learning the tool.
The Gray Area
Many decisions are not clearly one-way or two-way. They sit in the gray area where reversal is possible but moderately expensive. The skill is estimating the actual reversal cost rather than defaulting to "this is important, so let's treat it as one-way."
Decision Appears to be Actually is
--- --- ---
"Choose a web framework" One-way Two-way (early stage) to
one-way (after 100k LOC)
"Pick a database" One-way Depends on data volume.
10GB: two-way. 10TB: one-way.
"Adopt microservices" One-way Mostly one-way. Reverting
to a monolith is very hard.
"Hire this candidate" One-way More reversible than it
feels, but still costly.
"Add this column to the DB" Two-way Two-way if the table is
small. Borderline if it
has a billion rows.
Framework Choice: Two-Way Until It's Not
A common source of decision paralysis is framework selection. "Should we use Next.js or Remix? React or Vue? Express or Fastify?" These decisions feel important because they affect every file in the codebase.
But early in a project, framework choice is a two-way door. You have not written enough code for the switching cost to be prohibitive. The decision becomes increasingly one-way as the codebase grows.
Day 1: Framework choice is two-way. You have 0 lines of code.
Switching costs nothing.
Month 3: Framework choice is getting sticky. You have 20k LOC.
Switching is annoying but feasible.
Year 2: Framework choice is one-way. You have 200k LOC.
Switching is a rewrite.
The implication: decide quickly on day 1. If you chose wrong,
you'll know by month 3 and can still switch. If you deliberate
for 2 months on day 1, you've wasted time and still face the
same switching risk at month 5.
Public API Contracts: One-Way
A public API is one of the clearest one-way doors in engineering. Once external consumers depend on your endpoint signatures, response formats, and error codes, changing them breaks their code. This deserves the full one-way door treatment:
One-way door process for a public API:
1. Design the API on paper first. No code yet.
2. Review with at least 3 potential consumers.
3. Write integration tests against the contract.
4. Ship a beta version with explicit warnings about changes.
5. Gather feedback. Iterate on the beta.
6. Freeze the contract. Now it's permanent.
Compare this to choosing a logging library (two-way door):
1. Pick one.
2. Use it.
3. Switch if you hate it.
The investment in the API decision is 10x the investment in the logging decision. That is appropriate because the cost of being wrong is 100x higher.
Database Schema: Mostly One-Way
Schema decisions illustrate the spectrum well. Adding a column to a table with 1,000 rows is a two-way door — you can drop it in seconds. Adding a column to a table with a billion rows is a one-way door — the migration takes hours, locks the table, and cannot easily be undone.
Schema change Rows: 1k Rows: 1M Rows: 1B
--- --- --- ---
Add nullable column Two-way Two-way One-way
Add NOT NULL column Two-way Gray area One-way
Change column type Two-way One-way One-way
Drop a column Two-way One-way One-way
Normalize/denormalize Two-way One-way One-way
The reversibility depends on context, not just the operation.
Small table schema changes are two-way doors that become one-way
doors as data grows.
Feature Flags: Making One-Way Doors Two-Way
Feature flags are an engineering tool for converting one-way doors into two-way doors. By wrapping a change behind a flag, you can deploy it to production without committing to it. If it breaks something, toggle the flag off.
Without feature flag:
Deploy new payment flow → users see it immediately →
if it's broken, you need a hotfix and a rollback.
One-way door.
With feature flag:
Deploy new payment flow behind a flag → enable for 1% of users →
monitor metrics → if it's broken, disable the flag →
no rollback needed, no user impact beyond the 1%.
Two-way door.
This is why feature flags are so valuable. They do not change the technical difficulty of the feature. They change the reversibility of the deployment decision.
Applying the Framework to Process Decisions
The one-way/two-way door framework applies beyond technical decisions:
Process decision Door type Implication
--- --- ---
"Let's try standups" Two-way Try it for 2 weeks. Stop if
it doesn't help.
"Let's adopt SAFe" Mostly Hard to undo once roles,
one-way meetings, and tooling are
set up. Evaluate carefully.
"Let's use Jira" Gray area Switching project management
tools is painful but not
impossible.
"Let's hire a CTO" One-way The organizational impact
is deep and lasting.
Common Pitfalls
- Treating everything as one-way — the most common error. Teams apply heavyweight process to every decision. This kills velocity. Most engineering decisions are two-way doors. Move fast on them.
- Treating one-way doors as two-way — the less common but more damaging error. Shipping a public API without review, signing a long-term contract without analysis, or choosing a database for a billion-row table without benchmarking. These deserve careful treatment.
- Misclassifying because of sunk cost — "We've already spent 3 weeks evaluating options, so this must be a one-way door." No. The time spent deciding does not change the reversibility of the decision. It just means you spent too long on a two-way door.
- Ignoring how doors change over time — a decision that is two-way today may become one-way in six months. Framework choice is two-way on day one and one-way after a year. Recognize the window of reversibility and decide within it.
- Using the framework to avoid accountability — "It's a two-way door, so I don't need to think about it." Two-way doors still benefit from some analysis. The framework says "decide faster," not "decide recklessly."
Key Takeaways
- Two-way doors are reversible decisions. Make them fast, iterate, and course-correct. Most engineering decisions fall here.
- One-way doors are irreversible or very expensive to reverse. Invest in analysis, review, and deliberate process. Public APIs, large schema changes, and vendor contracts fall here.
- The main failure mode is treating two-way doors as one-way doors, which slows everything down. Train yourself to ask "how reversible is this?" before investing time.
- Feature flags convert many one-way doors into two-way doors by making deployment reversible.
- Reversibility changes over time. A decision that is two-way early in a project becomes one-way as adoption grows. Decide within the window of reversibility.
- The framework applies to process and organizational decisions, not just technical ones.