> ## Content Index > Fetch the complete content index at: https://mikegarcia.io/llms.txt > Use this file to discover other available public pages before exploring further. # The irreversible decisions go first - URL: https://mikegarcia.io/the-irreversible-decisions-go-first/ - Published: 2026-06-20T19:00:12.000Z - Updated: 2026-08-01T05:22:23.000Z - Description: Most risks are prices you can pay. The one with no affordable way back is different. Settle those decisions first, while you still have a choice. - Author: Miguel Garcia - Tags: Risk Management, Reliability, Distributed Systems, Platform Engineering, Migration 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. Or deadline, whatever'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 can't afford to take it, and for that project, a bill you can't pay is the same 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. You settle those decisions early, while keeping your options open is still cheap, and 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. Those weeks buy certainty, and you spend them on purpose. The validation has to pass the same test, though. The deadline won't give those weeks back. Spend them proving 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 that nobody on the team has run, which means learning it on the fly. 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, and the project absorbs it. ## **The irreversible path is often the fastest one** 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. The backups and spares sit on the wrong side of a barrier no one can cross, along with every recovery path, and there's 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. 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; a locked deposit would have fixed the yield, and 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, 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 will sort it out. 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 the risk out entirely, 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.