Build vs Buy Reversibility: Exit Cost and Optionality

The weighted matrix from Part 3 does one thing well: it scores the decision as it looks today. Fit, cost, time-to-value, differentiation — all measured against the situation in front of you. What it cannot see is the future in which you were wrong. The vendor triples the seat price at renewal. The build that was going to take two quarters is still limping through its fourth. The requirement you scored a 5 on turns out to matter far less than the one you didn’t think to weight at all. A matrix scores a snapshot. It says nothing about how expensive the snapshot is to un-take.

That expense has a name — reversibility, the exit cost — and it belongs in the decision as its own axis, because it behaves nothing like the others. A path can score beautifully on fit and cost and still be a trap, if the day you need to leave it arrives and leaving costs more than the original decision ever saved. This part prices the undo: what it actually costs to exit build, buy, and modernize; the two traps that catch people who never priced it (the vendor trap and the sunk-rebuild trap); the hybrid paths that are worth their complexity precisely because they preserve optionality; and the failure modes — real and expensive — that sit at the end of each path when reversibility is ignored.

Why reversibility is its own decision axis

Every option in front of you is also a bet on being wrong. That is not pessimism; it is arithmetic. You are choosing under uncertainty about requirements, vendors, technology, and your own future scale, and the base rate for those forecasts being exactly right over a five-year horizon is low. So the honest question is not only “which path is best if we’re right?” but “which path hurts least if we’re wrong?” Those two questions have different answers surprisingly often, and the gap between them is what reversibility measures.

The reason it is a separate axis — not something you can fold into the cost column — is that exit cost is a different kind of number from build or run cost. Build and run costs are things you can estimate up front and largely control. Exit cost is contingent: you only pay it in the scenario you were hoping to avoid, and its size is set by decisions you make now that feel irrelevant at the time. Whether you can leave a SaaS vendor cheaply in year four is determined almost entirely by three or four clauses and architectural choices you made in year zero, long before anyone was unhappy. That is the trap’s whole mechanism — the cost is invisible when it is cheap to prevent, and unavoidable by the time it hurts.

There is a useful discipline here borrowed from decision theory: distinguish one-way doors from two-way doors. A two-way door is a decision you can walk back through at low cost if it turns out wrong — those deserve speed, not deliberation. A one-way door is a decision that is expensive or impossible to reverse — those deserve real caution, because you are living with the consequence for years. The costly mistake is treating a one-way door like a two-way one: signing a deep, entangling vendor commitment or launching a from-scratch build of a load-bearing system with the casualness appropriate to a reversible bet. Reversibility analysis is, at bottom, figuring out which kind of door each path is before you walk through it — and, where you can, installing a hinge on doors that would otherwise only open one way.

Exit cost, path by path

Start with the shape of each path’s exit before the detail. What does it actually mean to leave each one, what do you pay to do it, and what — decided up front — lowers the bill?

┌────────────┬──────────────────────┬─────────────────────────────┬──────────────────────────────┐
│ Path       │ "Exit" means…        │ What you pay to leave       │ What lowers the bill (set     │
│            │                      │                             │ this up front, not later)     │
├────────────┼──────────────────────┼─────────────────────────────┼──────────────────────────────┤
│ Buy        │ Migrate off the      │ Data extraction & reshaping;│ Data-export rights in the     │
│ (SaaS/COTS)│ vendor onto          │ rebuild every integration;  │ contract; standard export     │
│            │ something else       │ re-implement customizations;│ formats; a documented         │
│            │                      │ retrain users; contract     │ integration seam; don't let   │
│            │                      │ exit / renewal cliff        │ it become system of record    │
├────────────┼──────────────────────┼─────────────────────────────┼──────────────────────────────┤
│ Build      │ Retire or absorb     │ Sunk build cost (mostly     │ Modular architecture; real    │
│ (in-house) │ your own system      │ unrecoverable); knowledge   │ docs and tests; keep the      │
│            │ into the next thing  │ that leaves with the team;  │ commodity parts swappable     │
│            │                      │ rebuild-from-scratch again  │ behind interfaces             │
├────────────┼──────────────────────┼─────────────────────────────┼──────────────────────────────┤
│ Modernize  │ Roll back a slice    │ One slice — small, proven,  │ Strangler-fig increments;     │
│ (incre-    │ to the known-good    │ behind a flag; a bad step   │ parity-tested cutover per     │
│ mental)    │ state                │ reverts, not a failed       │ slice; keep the legacy        │
│            │                      │ multi-year cutover          │ running until each slice wins │
└────────────┴──────────────────────┴─────────────────────────────┴──────────────────────────────┘

Read down the “what you pay” column and the asymmetry is stark. Two of the three paths have an exit cost you can drive toward zero with foresight; one of them, done incrementally, is cheap to reverse by construction. The dollars will differ by situation — plug your own into the legacy cost calculator — but the structure holds regardless of the numbers, and it is the structure that most decisions get wrong.

Buy: reversible on paper, entangling in practice

Buying is the easiest path to walk away from — if you protected your exit before you needed it. A product you use through a clean, documented boundary, whose data you can export in a standard format on demand, whose contract gives you an unambiguous right to that data, is a genuinely two-way door: unhappy in year three, you extract, re-point your integrations, and go. Plenty of SaaS relationships end exactly this cleanly, and nobody writes a cautionary tale about them.

The exit becomes brutal along a predictable path. You customize deep into the vendor’s proprietary model. You wire the product into a dozen systems without a clean seam between it and them. You let it quietly become the system of record for data that is central to how you operate. Now “leaving” means extracting data in whatever shape the vendor deigns to give you, reverse-engineering behavior that lives only inside their configuration, rebuilding every integration, re-implementing the customizations somewhere new, and retraining everyone — all while the business keeps running on the thing you are trying to escape. That is not a two-way door with a stiff hinge. It is a one-way door you walked through without noticing, because on the day you walked through it the door was still open.

Build: your code, but your cost is sunk

Building is reversible in a narrow, almost academic sense — it is your code, nobody can revoke your license to it, and in principle you can change anything. But you rarely undo a build in the way you undo a purchase. What you actually do is let it rot, or absorb it into the next thing, and either way the money is gone. The build’s cost is sunk: the salaries, the year of calendar time, the opportunity cost of the best engineers not working on what customers pay you for — none of it comes back when the system turns out to be wrong. Worse, a large part of what you paid for was the institutional knowledge of how the thing works, and that asset has legs. When the team that built it disperses, the reversibility you thought you had — “it’s our code, we can always change it” — evaporates, because the people who understood the code are gone and what remains is a system nobody alive fully understands. A build you can no longer confidently change is not a reversible asset. It is a legacy system you made yourself.

Modernize: the most reversible by design

Modernization done incrementally is the most reversible path of the three, and it is reversible by construction rather than by luck or foresight. The strangler-fig approach replaces a legacy system one slice at a time, each new slice proven to behave identically to the piece it replaces before it takes live traffic, with the legacy still running underneath as the fallback. A wrong step in that process is not a failed cutover you have to survive — it is a single slice you flag off, reverting to the known-good state you never actually left. You are never more than one increment away from where you were. Compare that to the big-bang alternatives: a from-scratch build or a rip-and-replace purchase both ask you to leave the old world entirely and land in the new one in a single leap, with the exit — if the landing goes wrong — being the most expensive one there is. Reversibility is the quiet reason incremental modernization de-risks a transformation that sounds, on paper, slower and scarier than just buying a finished product.

The two traps

Ignore exit cost long enough and you fall into one of two traps. They are mirror images, they catch different organizations, and both are entirely preventable at the point of decision and nearly unfixable once sprung.

The vendor trap

The vendor trap is buying so deeply that the vendor’s pricing and roadmap now set yours. It rarely arrives as a single bad decision; it accretes. Each customization, each new integration, each additional workflow you move onto the platform is individually reasonable and collectively a set of shackles. The tells are consistent across every version of this story: data you cannot cleanly export, so leaving means a data-archaeology project on top of everything else; a per-seat or per-consumption curve that climbs faster than the value you get, because switching costs let the vendor raise prices into your inelasticity; a renewal you cannot credibly walk away from, which means you are not really negotiating; and differentiating logic that now lives inside the vendor’s configuration layer, where it is neither yours nor portable. This is the specific failure that reversibility planning exists to prevent, and the prevention is cheap: it is a handful of contract clauses and architectural boundaries put in place while you still have leverage, which is before you sign, because your leverage is never higher than the moment before the ink dries.

The sunk-rebuild trap

The mirror image catches the build-it crowd. The sunk-rebuild trap is pouring engineering years into a from-scratch build — often of something that was never differentiating in the first place — and then being unable to walk away from it precisely because you spent so much getting there. The sunk cost is doing exactly what the fallacy predicts: the more you have invested, the harder it becomes to admit the investment was wrong, so you keep funding a system whose honest disposition is “retire it.” The build limps forward, absorbing maintenance headcount and blocking the roadmap, kept alive not because it is the right answer but because killing it means writing off the money and the pride. The trap is baited with your own prior spending, and the only escape is the discipline to treat sunk cost as sunk — to ask “what is the right decision from here?” as if the past investment were someone else’s — which is exactly the discipline the sunk-cost fallacy exists to defeat.

The hybrid paths that preserve optionality

Between “build everything” and “buy a finished product” sits a spectrum, and the middle of it is where a lot of the smart money now sits specifically because those options keep more doors open. Reframe the hybrids not as compromises but as optionality-preserving structures — each one is a way to get most of the value of a commitment while keeping the exit cheaper than a full build or a deep buy would.

Buy-then-extend

This is the highest-optionality hybrid, and often the best answer for a capability that is 80% commodity and 20% yours. You license a platform for the commodity majority, then build your differentiator on top of it through the platform’s APIs and SDKs — keeping that competitive logic as your own code, on your side of the API. Salesforce, SAP BTP, ServiceNow, Workday, and Shopify all exist partly to be extended this way, and the pattern generalizes far beyond them. What makes it reversibility-preserving rather than just convenient is the API boundary itself: the seam you build across is the same seam you would exit through later. Your differentiating logic sits in code you control and can carry to another base if you have to; the vendor’s maintained platform handles the undifferentiated 80% you were never going to win on anyway.

The discipline that makes it work — and the failure that ruins it — is a single decision made over and over: where does the differentiating logic live? Put it on your side of the API, in your code, and buy-then-extend keeps its optionality. Bury it inside the vendor’s proprietary customization layer — their scripting language, their configuration engine, their point-and-click builder — and you have quietly converted a two-way door into the vendor trap, because the thing you compete on is now un-portable and the vendor knows it. Same platform, same features used, opposite reversibility, decided entirely by which side of the line your competitive logic sits on.

Partner / co-development

When the capability is genuinely core but your team cannot staff or build it fast enough, a partner or co-development arrangement buys expertise and velocity without buying a fixed product that fits someone else’s problem. You bring the domain and the differentiating requirements; a specialist brings the build muscle and often co-owns the delivery. On the reversibility axis, this sits in the middle and its exit cost is governed almost entirely by the contract and the handoff: does the code, the IP, and the documented knowledge come to you cleanly at the end, or does the partner retain enough of the understanding that you are dependent on them indefinitely? A partner engagement that transfers real ownership — code, docs, and the tribal knowledge of how it works — leaves you with something you can run and change yourself, which is reversible. One that leaves you holding a working system nobody on your side actually understands has simply relocated the sunk-rebuild trap to an invoice with someone else’s name on it. Structure the handoff, or you have bought a dependency dressed as a capability.

White-label / OEM

You license someone else’s engine — a payments rail, a mapping layer, a document-generation service, a search index — and put your brand and workflow on top. Stripe and Adyen for payments, Twilio for communications, an established mapping or search vendor for those layers: the value is getting to market fast and skipping the build of undifferentiated, hard-to-operate infrastructure that a specialist does better, cheaper, and more securely than you ever would. The reversibility cost is a real dependency on the vendor’s roadmap, pricing, and uptime, and it is worth being clear-eyed that this is a deeper commitment than a peripheral tool. The mitigation is the same principle as buy-then-extend: integrate through a thin abstraction of your own rather than letting the vendor’s specifics leak across your whole codebase, so that swapping engines later is a bounded project against a known seam rather than a search-and-replace across everything you own. Many teams keep this exit credible by choosing categories with more than one viable vendor, so the option to switch is real rather than theoretical.

Low-code / no-code

Platforms like Retool, Airtable, Power Apps, Mendix, and OutSystems let you assemble internal tools and line-of-business apps far faster than a full build. They are the right tool for the context layer — internal workflows, admin panels, approval flows, dashboards — where speed matters and the thing you are building is not what you compete on. Their reversibility profile is specific and worth understanding: for the lightweight internal tools they are meant for, the exit cost is low precisely because the stakes are low — if you outgrow the platform you rebuild a modest internal tool, which is annoying but bounded. The trap is dragging a genuinely differentiating, high-scale product onto a low-code platform because the early velocity felt irresistible, and then hitting the platform’s ceiling with no clean way down. At that point you own a business-critical system trapped inside a tool that was never meant to carry it, with an exit that means rebuilding the whole thing properly under duress. Low-code preserves optionality for context and destroys it for core — use it accordingly.

Failure modes on both sides

Both build and buy have graveyards, and they rhyme. Each one is what the corresponding trap looks like after it has fully sprung and the exit cost has come due. The lesson in both is the same: the failure was set up years earlier, at the decision, by not pricing the undo.

The over-customized COTS graveyard (buy side)

The classic buy-side failure is licensing a package for its standard capability and then spending years — and fortunes — bending the software to match processes the organization should have adapted instead. The customization backlog grows faster than the vendor’s roadmap; upgrades you can no longer take pile up because your modifications would break; and the “bought” system ends up costing more to run and maintain than a build would have, while being harder to leave than either.

The widely reported cautionary tale here is Lidl. The German retailer ran a multi-year program (known as eLWIS) to replace its legacy inventory and goods-management system with SAP, and in 2018 it scrapped the effort after roughly seven years and reverted to its existing system. The reason most consistently reported is instructive for this exact discussion: Lidl had long valued inventory at purchase price rather than the retail-price model SAP’s standard system assumed, and rather than change that deeply embedded practice, the project tried to bend the software to fit it — a customization burden that reportedly grew until the whole program collapsed under its own weight, with press accounts putting the write-off in the region of half a billion euros. Whatever the precise figure, the shape is the canonical over-customized-COTS failure: a package bought for standard capability, then forced to match existing process until its economics and its maintainability both broke. It is not the only example in the genre — the enterprise-software press has documented a string of large ERP programs abandoned or written down after implementations tried to make the software fit the company rather than the reverse — but Lidl is the cleanest, most widely reported illustration of the specific mechanism, and it is the mechanism, not the logo, that should worry you. The tell to watch for in your own program: a customization backlog outrunning the vendor’s roadmap, upgrades you can no longer take, and a bought system that now costs more to run than a build would have.

The doomed rebuild of commodity software (build side)

The mirror-image failure is a team building its own version of infrastructure that mature products already do better, cheaper, and more securely — its own billing engine, its own authentication and identity system, its own search, its own feature-flag service, its own job scheduler. Year one it is a point of pride and, often, a genuinely reasonable-looking decision in the moment. Year three it is a two-person tax nobody wants to own, perpetually behind on the edge cases, the compliance obligations, and the security hardening that the commodity vendors handle for every customer at once and roll out for free. Most engineering organizations have at least one of these, and the pattern is consistent enough to state as a rule: the further a home-built system sits from what you actually compete on, the more surely it becomes a liability you cannot easily retire, because the sunk cost and the “it works, don’t touch it” inertia keep it alive long past the point where any honest analysis would replace it with a product.

Authentication is the textbook case, and it is textbook for a real reason rather than an invented one: rolling your own auth or crypto is widely cautioned against across the security profession precisely because the edge cases, attack surface, and standards churn are enormous, specialized, and unforgiving — exactly the profile of work where a maintained product’s amortized expertise beats any single team’s part-time attention. A composite that plays out in some form at countless companies: a startup builds its own auth in the early days because a login page seems trivial; five years later it is carrying session management, password-reset flows, MFA, SSO, and a lengthening list of compliance requirements on infrastructure two engineers understand and nobody wants to own, having reproduced — worse, and at permanent cost — something it could have licensed for a fraction of the total. The specifics vary; the shape does not. That is the sunk-rebuild trap wearing engineering pride as a disguise.

Notice the symmetry between the two graveyards. The COTS failure buys something standard and then destroys its value by making it bespoke. The build failure builds something bespoke that should have stayed standard. Both are failures to answer the same question honestly — is this capability something we actually compete on, or is it plumbing? — and both would have been caught by pricing the exit before committing, because in both cases the exit cost was screaming its warning years before anyone was willing to hear it.

Designing for reversibility: install the hinge up front

Reversibility is not something you assess once and file away; it is something you build in, and the whole point is that it costs almost nothing at decision time and is nearly impossible to retrofit later. The practical discipline reduces to a short list, and every item is cheap now and priceless the day you need it.

• Secure the data before you need it. Insist on standard export formats and a contractual right to your own data, in writing, before you sign. A vendor unwilling to guarantee clean data portability is telling you something about the exit they intend you to have.
• Keep a documented integration seam. Integrate every bought or partnered component through a thin boundary of your own rather than letting its specifics leak across your codebase. The seam you build across is the seam you exit through — a bounded project instead of an archaeology dig.
• Keep differentiating logic on your side of the API. For anything you buy-then-extend, your competitive logic lives in your code, portable, never buried in the vendor’s proprietary customization layer. This single rule is the difference between buy-then-extend and the vendor trap.
• Modernize in reversible increments. Where you keep and transform a system, replace it a slice at a time, each one held at the parity gate and put behind a flag, with the legacy running underneath — so a wrong step reverts to known-good rather than failing a cutover you cannot undo.
• Treat sunk cost as sunk. For anything you build, keep asking “what is the right call from here?” as if the money already spent were someone else’s. The sunk-rebuild trap is defeated only by refusing to let prior investment vote on present decisions.

None of these is expensive at the moment of decision. All of them are effectively impossible to add once the trap has closed. That asymmetry — cheap now, unbuyable later — is the entire argument for pricing reversibility before you commit rather than discovering its cost the day you try to leave.

Where this leads

Everything to this point — the frame, the cost, the matrix, and now the exit price — has treated the system you already have as the problem: the thing to replace, whether by building its successor, buying its replacement, or hedging with a hybrid. But there is a case the whole build-vs-buy framing quietly assumes away, and it is more common than the framing lets you see. Sometimes the system you have is not the problem to be replaced at all. Sometimes it is the asset — the place where years of hard-won business logic already live — and transforming what you have beats both building something new and buying something generic, precisely because it carries that logic forward instead of forcing you to rediscover it. That is the third option this series has been circling, and Part 5, When Modernizing Wins, makes the case for it directly.