The irreversible decisions go first

Rank your decisions by whether you can undo them.

Most ranking schemes use a different axis. Size: do the big, scary thing carefully. Dependency: do what unblocks the most work. Deadline: do what's due first. You already split your decisions into the ones you can walk back and the ones you can't. Right instinct, stopped one step short. Reversibility is a recovery cost, and that cost climbs the longer you wait to act.

The decision that settles whether the project survives a mistake is rarely the biggest one on the board. It's the one whose way back is about to close.

A decision's price is its recovery cost

A wrong decision costs whatever it takes to recover from it. Nothing more, as long as you can afford the bill.

That makes most mistakes cheap. A reversible decision has a bounded recovery cost: back it out and you're where you started, minus some time and money. Over-provisioned the cluster? Scale it down. Wrong library? Swap it, even if the swap burns a sprint. You can see the edge of the bill before you choose.

Two things erase that edge. The first is an irreversible decision: when it fails, there's no earlier state to return to. The effort and the money are already spent; what you lose is the road back itself. You shipped a custom format to a million devices, or signed the three-year contract. You deleted the only copy. The second is quieter: a recovery cost that's finite but bigger than your budget. There's a way back, you just can't afford to take it, and for that project a bill you can't pay is the same wall as no way back at all.

So the risks sort into a hierarchy, and one tier sits apart:

• Effort is recoverable. Spend more of it.
• Cost is recoverable, up to your budget. Find more, or eat the loss and keep going.
• Learning is recoverable while time remains. The team that doesn't know the platform today learns it by running it.
• A way back you can't afford, or don't have, is none of these. Its failure mode is the project ending.

Effort, cost, and learning are prices. Pay them and continue. The lost road back is the one outcome the other three can't buy off.

Settle the irreversible decisions first, commit them last

If the unaffordable risk is the one with no affordable way back, the ordering follows. Confront those decisions first; commit to them last. You settle them early, while keeping your options open is still cheap. You commit only when staying flexible costs more than the risk it covers.

That early work has a visible price. Proving out an irreversible decision means a proof of concept, a rehearsal, weeks that produce nothing you can ship. You pay for certainty, not for shipped work, and you pay on purpose. The validation has to pass the same test, though. Spend weeks the deadline won't give back to prove out a decision you could have cheaply reversed later, and the validation itself becomes the irreversible bet. You just moved it onto your calendar.

A migration runs against a hard cutover deadline that can't move, no downtime allowed. One path is a bespoke control layer. As proposed, it has no fallback, and building it would burn the whole cutover window. By the time it ships, there's no way back to anything else. The other is a proven platform nobody on the team has run, which means learning it against the clock.

The bespoke build is the irreversible call, so it gets settled first. It comes off the table before a line of code, because effort and learning are recoverable and a no-fallback architecture is not. The early weeks go to testing the proven platform against every requirement, while there's still room to choose something else. Weeks in, the platform turns out to miss one requirement nobody could have caught up front. The way back is still open, so the fix costs a sprint, not the project.

The discipline is hardest when the irreversible path is fastest

In a planning meeting, this is easy. Under pressure, the fastest option is often the one that spends the asset you can't replace.

An outage puts the only copy of the data behind the same failure that took the system down. The copies were never spread across locations, so a reversible decision has quietly gone irreversible. Backups, spares, recovery paths sit on the wrong side of a barrier no one can cross, with no way to clone any of it first. Downtime compounds by the hour. The fast fix on offer is to physically move that single copy to a working site and be back up within the hour.

Take it, and you trade a recoverable problem for a maybe-unrecoverable one. Downtime ends because recovery is still possible. A drive lost in transit does not come back, and nothing stands behind it. The disciplined move is to keep eating the expensive, reversible damage, more hours dark, instead of reaching for the fast fix that gambles the one thing with no recovery. Downtime is recoverable. The data is not.

The ranking holds outside engineering

None of this belongs to infrastructure. The same ranking governs any commitment.

A bootstrapped company held twelve months of operating expenses in idle, liquid cash for a decade, rode a swing of several times over between its best year and its worst, and never borrowed. Idle cash earns almost nothing; the yield it gives up every month is a real price. A loan would have freed that capital to work elsewhere.

Both got refused for the same reason. Anything you can't pull back to cash the morning a payment comes due can't cover that payment, which rules out the locked deposit. Debt is an obligation you can't unwind when revenue craters, which rules out the loan. The forgone yield was a price the company paid every month, on purpose, to keep from ever holding a commitment it couldn't reverse under pressure. The reserve was a survival floor, not a return to maximize, and it was funded to exactly that floor and no higher.

Effort, cost, and forgone yield are prices you can pay. The commitment you can't reverse under pressure is the one to design out before it forms.

Two questions sort the unaffordable risk from the rest

Before you commit resources to a decision, two questions sort it. First: if this goes wrong, is there still a way back I can afford? Second: when does that way back close?

The decisions where the first answer is no, or about to become no, go to the front. You spend your earliest, cheapest optionality on them, by validating them, refusing them, or designing them out, whichever keeps the door open. Keep paying only while the door is worth more open than shut. Then commit.

A project survives its mistakes only as long as it can still walk them back.