The Exit Cost Is Never on the Invoice

Last week I argued that the cost of undoing a decision is not created at the decision. It accretes afterwards, through every later choice that quietly assumes the hard-to-reverse thing will stay put. I wrote it about code. A schema, a scheduler, an interface that four teams built on without anybody calling it an architecture decision.

The replies came back from people who do not write code. Someone who runs procurement evaluations. Someone whose job is third-party risk. An advisor looking at five applications doing the same job for one company. An enterprise architect arguing about who should own which AI capability. Different rooms, different vocabularies, and every one of them was describing the same mechanism.

That is usually the sign you drew the boundary in the wrong place. Accretion is not a property of source code. It is a property of dependency, and most of the dependency in a large organisation was bought rather than built.

Which surfaces a question that sounds like it should already have an answer. What would it cost you to leave? Nobody has that number. Everybody has the other one.

The contract prices staying, not leaving

A supplier relationship gets assessed properly exactly once, and it is at the beginning. Security questionnaire, SLA, references, financial health, penetration test summary, sometimes a site visit. Real work, done by people who are good at it. Then the relationship moves into the register as a rated risk and gets reviewed annually, which in practice means somebody confirms nothing has changed.

What that process measures is the supplier's posture today. How likely they are to fail you, how badly, how well they would handle it.

It does not measure the thing that decides what you can do about any of it. If this supplier degrades, gets acquired, triples their price at renewal or simply stops being the right choice, your options are not set by their posture. They are set by how hard they are to leave. And that number appears nowhere in the assessment, because at the moment you are doing the assessment it is close to zero. Day one, you could switch in a fortnight. There is nothing to plan for, so nobody plans for it.

Yes, the contract has an exit clause. It has notice periods and data return obligations and a transition assistance paragraph that somebody negotiated hard. All of that prices the legal exit. None of it prices the operational one, and the operational one is the whole bill.

The paperwork tells you a supplier's posture today. It tells you nothing about how hard they will be to leave once you depend on them.

It accretes out of sight

The mechanism is the one from last week, running in a place with worse instrumentation.

Month by month, the integration gets deeper, and not because anybody decided to deepen it. Their identifiers become your identifiers, because carrying your own and mapping theirs was extra work nobody could justify. Their status values end up in your reports. The order their webhooks happen to arrive in becomes an assumption your reconciliation logic depends on, undocumented, discovered late. Your support team builds its process around their ticket flow. A finance report exists in the shape it does because that is the shape of their export. Two people on the team know the quirks well enough to work around them, and that knowledge is the reason things run smoothly, and it is also a cost of leaving that nobody has ever written down.

Not one of those was an architecture decision. Each was a reasonable local choice made by someone with no reason to consult anybody. The dependency became less reversible every month while the risk register recorded it as settled.

Inside your own system you at least have a crude instrument. A dependency graph shows you callers. It misses plenty, as I keep saying, but it shows you something. Across a supplier boundary you do not have even that. You can list the integration points, because those are in a config file somewhere. You cannot list the adaptation, because the adaptation is in processes, reports, habits and two people's heads.

So the test that works is embarrassingly simple, and you can run it this week. Ask what actually breaks if we leave, and time the answer. If it comes back in an afternoon, you still have the option. If the honest answer is that somebody would have to go and find out, you lost the option a while ago and nobody told you.

Sometimes what you bought was a process

There is a version of this that is sharper than lock-in, and it gets missed because it does not look like a dependency at all.

Federate identity to a provider and you have not simply chosen a login mechanism. You have adopted their joiner, mover and leaver process. You do not run it. You cannot observe it. You have no instrumentation on it. And from that day, a contractor leaving your organisation is a state change in a system that belongs to somebody else, which your entire estate now trusts.

The line in the architecture review says we trust this provider. What it actually says is that we adopted their offboarding behaviour without ever assessing it. Those are different claims and only one of them got written down.

This is not an argument against federating. Federating is usually right, and the alternative is five local identity stores that are worse in every dimension. It is an argument that the decision you made was bigger than the decision you recorded, which is the oldest problem in this series. The same shape shows up any time you buy a managed service: you bought a capability, and along with it you silently adopted an operational procedure you will never see run.

None of it is on the invoice

The clearest live example is AI tooling, where the debate has settled into own versus buy. Build the capability in house and keep sovereignty, or buy the tool and accept the dependency.

Ownership and dependency are not the same axis, and treating them as one is how organisations end up buying sovereignty they do not have.

Everybody watches the contract and the API surface, because those are the visible parts. Swapping a provider endpoint is the easy half of the work and it is the half people estimate. What cannot be swapped is the accumulated adaptation. Prompts tuned over months against one model's particular quirks. Evaluation suites written to describe its specific behaviour, which means your definition of working now has that model's shape baked into it. Workflows, review steps and team instincts reorganised around what this model happens to be good at and what it reliably gets wrong.

None of that is on the invoice, and all of it has to be rebuilt.

Which is why we will deal with sovereignty later is an expensive position rather than merely a late one. The dependency does not wait politely while the question stays open. It grows precisely during the period you are postponing the decision, so the cost of the answer you eventually give is set by how long you took to ask.

The evidence you should have asked for

If the exit cost is what matters, then the evidence you demand before signing should scale with it. Low reversal cost, a written answer is fine. High reversal cost, a written answer is close to worthless.

And there is a nasty inversion inside that, which I have paid for personally. The claims that cost the most to unwind are exactly the ones that survive every demo. Handles retries safely. No double processing. Tenants stay isolated. Those all pass, every time, in the sandbox, in the walkthrough, in the reference call, because the failure was never in the logic the supplier is showing you. The failure is in what real volume, real concurrency and real retries do to that logic, months after you integrated, at which point the claim is a foundation rather than a line in a proposal.

So for those specific claims the right evidence is not a scripted demonstration. It is a test built to break the invariant. Replay the identical trigger twice and show me one result. Hit it concurrently and show me the state afterwards. Two tenants, one adversarial query, show me the empty response. It takes a day and a sandbox account. If it holds you learned something real, and if it does not, you learned it while walking away still costs nothing.

A written answer flatters exactly the claims that are most expensive to unwind.

Design the exit while it is still free

The timing asymmetry is the same one as last week, and it is the whole reason to care at signature rather than at renewal.

At signature, deciding what stays swappable costs an afternoon of argument. Keep your own identifiers and map theirs at the edge. Keep their vocabulary out of your domain model, so their status values never become your status values. Write down which data you would need on the way out, in what format, and then actually run that export once, because an export you have never executed is a claim rather than a capability. Every one of those is cheap while the joint is still open and close to impossible to retrofit into a year of accumulated integration.

This is not a case for wrapping every supplier in an abstraction layer. That is the over-optionality failure from last week wearing a procurement badge, and it ends the same way: an interface built so you can swap the thing you will never swap, carried for years, paid for daily. The pricing rule does not change. Design the exit where being wrong is both expensive and plausible. Data you cannot recreate. A shape other teams will build on. Something sitting between you and your customer. Everywhere else, sign it and get on with the work.

And when you do want a natural moment to price it, renewal is the only one the calendar gives you for free. It is also the one most organisations waste, because auto-renewal is the purest form of this entire problem. The dependency extends itself for another three years and nobody has to decide anything. Flip that, and whoever signs the renewal owns the decision to keep it, which means somebody finally has a reason to ask what leaving would cost.

That question is what portfolio consolidation actually stalls on, by the way. Licence spend, infrastructure, contract value and utilisation are all collectable, and organisations collect them diligently. But the number that determines whether five applications become one is the cost of removing four, and that number is on no spreadsheet, because it did not exist when the duplication started. It accreted, one integration at a time, each built against a duplicate while it happened to be there. Ten thousand saved by not deciding, half a million to remove five years later, and everybody calls the result legacy.

The rule I'd leave you with

Assess a supplier and you have measured how likely they are to fail you. Useful, and not the thing that governs your options.

Measure your exit and you have measured what you can do about it, which is the only part of the relationship that is genuinely yours. Do it at signature, where it is nearly free. Demand evidence in proportion to what being wrong will cost, and hold that bar hardest on the claims that demo beautifully. Keep the option where the damage would be real, and skip it everywhere else, because uniform caution here buys the same nothing it buys anywhere.

Then write down, once, what you believed made this one easy to leave. Not for the file. For whoever discovers in three years, possibly you, that it stopped being true, and cannot tell whether anybody ever knew.

So here is the question I would actually want answered about your own estate. Take the supplier you would least like to lose, and ask how long it would take your organisation to say precisely what breaks if they were gone on Monday. If the answer is that somebody would have to go and find out, you already know the exit cost, and it is higher than anyone has written down.