The Door You Can Walk Back Through

A framework note: what follows applies Felix Stein's one-way / two-way door analysis — published at https://www.lean-agility.de — to how Apuna makes decisions. Stein's treatment of the Bezos model is the ground truth here; the Apuna application is mine. The Bezos quotes appear in their original English.

Jeff Bezos named the problem in his 2015 shareholder letter, and Felix Stein gave it a crisp structural framing at https://www.lean-agility.de that I find myself returning to whenever Apuna's decision discipline comes up for review.

The distinction is simple. Some decisions are one-way doors — Type 1. You walk through, the door closes behind you, and there is no going back. Bezos:

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don't like what you see on the other side, you can't get back to where you were before.

Other decisions are two-way doors — Type 2. Reversible, reopenable, correctable. And here is the line Bezos wrote that most organisations read past:

As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention. We'll have to figure out how to fight that tendency.

Slowness, risk aversion, diminished invention. That is the failure mode of a small collective just as much as a large corporation — perhaps more so, because a small team has fewer tokens of attention to waste on ceremony.

The structural defect Apuna carries

Apuna's fast-lane rule currently reads: single-file, no public / auth / data / legal / money impact — go directly to Engineer without the full ceremony. On its face, a useful heuristic.

But file-count is a proxy for size, not for reversibility. A five-file copy-and-style change is a two-way door; one command undoes it in minutes, CI is green, the blast radius is narrow. A one-file change to an auth token is a one-way door the moment it touches an external service. The gate is keyed to the wrong variable.

The more precise test: can one command revert this within roughly five minutes, with a narrow blast radius, and with CI still green? That is the reversibility question. That is the question the gate should answer. Keying it to file-count instead is itself the Bezos failure mode — applying Type-1 process (full pipeline) to Type-2 work (a multi-file copy change) out of reflex, not judgment.

The standing rule "when in doubt, use the full pipeline" has the same defect at the margin. Genuine doubt about reversibility is a signal worth heeding. But if "in doubt" is interpreted as "the file-count is above one," the rule converts a useful safety net into a brake on the work it is supposed to serve.

Atomic PRs as two-way doors

Apuna's atomic PR practice is, structurally, a two-way door made explicit. A CI-green, squash-merged, branch-isolated pull request is reversible by construction: git revert, one command, traceable. The practice already names the right unit. What the codex does not yet say clearly is: name atomic PRs as two-way doors, and treat them accordingly — stop pulling them toward Type-1 ceremony.

This is Stein's second conversion mechanism — changing the system design so that decisions that used to be one-way become two-way. Atomic PRs are modular by design. The modularity is the door mechanism. The discipline is to honour it rather than draping Type-1 process over it out of organisational habit.

Deploys: disaggregating the claim

The simplest version of the one-way/two-way model applied to software says: merges are two-way, deploys are one-way. That version is imprecise.

A prod deploy at Apuna is two-way at the code and infrastructure layer. wrangler rollback --name apuna-web promotes the previous deployment with no rebuild — one command, no redeploy required. That is a door mechanism. The rollback exists.

But a rollback reverts the bits. It does not revert the consequences.

A public blog post that is live for twenty minutes under apuna.dev has been cached by search engines, screenshotted, and read. The file is reversible; the fact that it existed publicly under the firm's name is not. A Brevo outbound email cannot be unsent. A credential that leaked into a client bundle cannot be un-seen. Those side effects survive the rollback. They are one-way at the side-effect layer even though the code is two-way at the infra layer.

The precise finding, then — and this is what the gate should key on — is: gate the deploy if and only if it produces an irreversible external side effect. Not because the deploy itself is one-way, but because some things that travel with a deploy cannot walk back through the door. The gate belongs at the side effect, not at the code change.

Operational consequence: the current blanket "deploys always need founder confirmation" bundles genuinely irreversible operations (email sends, public legal or pricing commitments, leaked credentials) with revertable code-and-content deploys. Splitting that bundle — keeping confirmation for true one-way items, downgrading to notification for revertable deploys — is the structural improvement available here. But there is a condition on that conversion.

The condition: an untested conversion is fictional

Stein notes that converting one-way doors to two-way ones typically costs something — detail control, or money, or standing infrastructure capacity. The conversion is not free; it must be deliberately built.

The same logic applies to rollback. The wrangler rollback command is documented. Whether it is drilled — timed, rehearsed under stress, known to the whole crew — is a different question. An undocumented or undrilled rollback is not a two-way door. It is a story about a two-way door, painted on the wall. The crew walks through boldly and finds, in the moment they need to walk back, that there is no mechanism behind the picture.

Until rollback is rehearsed and timed — sub-five-minutes under stress is the target — the deploy gate is load-bearing and earns its friction. Converting it to a notification is conditional on that drill, not on the documentation alone.

Which doors to keep deliberately heavy

Converting one-way doors to two-way is a discipline, not a default. Some doors should remain Type-1, named and accepted as such. At Apuna's current scale the list is not long, but it is load-bearing:

Outbound email sends. Destructive data migrations (a Worker rollback does not un-run a migration). Secret and credential rotation. DNS changes. Public legal, pricing, or SLA commitments — you cannot un-say a price to a client who relied on it. Hiring and contracting a crew member. Architectural lock-ins already walked through — the @opennextjs/cloudflare adapter, for instance, is a one-way door that has already closed.

These stay Type-1 because the irreversibility lives in the external world, not in the code. No amount of system redesign converts them to two-way without the external world cooperating. Name them, keep the gate, and spend the ceremony on them honestly — not on a multi-file copy change that CI covers.

The one structural principle

Re-key the gate. Not file-count. Not "single-file." The question is: can one command undo this within minutes, with a narrow blast radius, and CI green? If yes, two-way — move. If no, Type-1 — slow down, consult, decide with deliberation.

Stein's insight, which I take from his https://www.lean-agility.de piece, is that agility is not only comfortable in two-way doors. Its more important work is converting one-way doors into two-way ones wherever that conversion can be honestly built. Atomic PRs at Apuna are that conversion, already made. The drilled rollback is that conversion, not yet made. The founder gate disaggregated by door type — confirmation for true one-way items, notification for revertable deploys — is that conversion, available once the rollback is real.

Structure should serve the work, not the org chart. The question every gate earns is: which kind of door is this, honestly — and have we built the mechanism that makes that claim true?

Felix Stein's original piece, on which this analysis builds, is at https://www.lean-agility.de. The Apuna application and any errors in it are mine.