Exit Cost

A company buys a feature-flag and experimentation platform for a price that is obviously cheaper than building one. Three years later the vendor is acquired, the price for the same usage triples at renewal, and the team discovers that flag checks are scattered through 40 services, experiment assignment logic lives in the vendor's SDK, and three years of experiment history exists only in the vendor's system. The renewal is not a negotiation, because there is no alternative that can be executed in the time available.

Exit cost is the number that was missing at purchase: engineer-months plus elapsed calendar time to be running without this vendor. It is not the same as lock-in as a feeling. It is measurable, it can be designed down, and it is the only input that makes the phrase "vendor risk" actionable.

Why it matters

Exit cost determines price at renewal. A vendor's pricing power is bounded by what it would cost you to leave, and both sides know the number even when only one has computed it. A capability with a two-week exit gets market pricing. One with a nine-month exit gets whatever the vendor decides, because the alternative is a project nobody can fund on notice.

It also determines whether "buy" was the right call at all. The build-versus-buy comparison is normally run on build cost against subscription cost. Adding exit cost changes the ranking of otherwise similar options: two vendors at the same price with exits of three weeks and six months are not the same purchase, and the cheaper-looking one is frequently the expensive one.

Implementation patterns

• Estimate it at purchase, in engineer-months and calendar weeks, and put the number in the decision record. Revisit it annually, since it grows on its own.
• Keep the vendor behind your own interface. An internal abstraction the application calls, with the vendor's SDK behind it, converts a 40-service change into a one-module change. The cost is a thin layer and giving up the vendor's most specific features.
• Export continuously, not on exit. Data you can only retrieve through the vendor's UI is data you do not have. A nightly export into your own storage is cheap and collapses a large part of the exit.
• Prefer open interfaces where the capability is commoditised — object storage APIs, SQL, OpenTelemetry — so a competitor is a configuration change rather than a rewrite.
• Run a paper exit once a year: name the replacement, the migration steps and the elapsed time. This is a two-hour exercise that keeps the number honest and is worth more than any contract clause.
• Budget the exit before the renewal. Notice periods are typically 30 to 90 days, and a six-month exit inside a 60-day window is not an option anyone can exercise.

Industry example

The clearest public examples are at the other end of the scale. A file-sync company moved its file storage off a public cloud provider onto its own infrastructure around 2016, an exit that was economically rational only because storage was the dominant cost of the business and the volume ran to exabytes — the exit was affordable because the capability was worth owning. For everyone smaller, the lesson runs the other way: the same migration for a company with a thousandth of the volume is an exit cost with no corresponding benefit. The decision rule that falls out is to pay exit cost only where the capability is the business, and to design it down everywhere else.

Failure scenarios

• Renewal at a multiple, with no time to move, because the exit was never estimated.
• Acquisition or end-of-life of a vendor, converting a voluntary migration into a deadline.
• Data hostage: history retrievable only through the product, so leaving means losing years of records.
• Deep coupling through an SDK whose semantics — assignment, ordering, identity — have no equivalent elsewhere, so the migration is a behaviour change as well as a code change.
• A compliance change the vendor cannot meet, making exit mandatory on a regulator's timeline rather than yours.
• Exit cost that grew silently from three weeks at purchase to six months, because every new service integrated directly.

Trade-offs

Keeping exit cost low is not free. An abstraction layer costs engineering time and gives up the vendor's differentiated features, which is often exactly why the vendor was chosen. Wrapping a deeply differentiated product reduces it to its commodity subset and wastes the premium being paid. The judgement is per capability: wrap the commoditised ones, integrate deeply with the one or two where the specific capability is the reason for buying, and accept a high exit cost there knowingly, with the number written down.

When not to use it

Do not spend effort on portability for capabilities where exit is inherently cheap — transactional email, SMS delivery, error tracking — where the interface is small and competitors are interchangeable. A generic wrapper around an already-generic API is pure overhead. Do not use exit cost as an argument for building either: the exit cost of your own system is not zero, it is the cost of maintaining it forever, which is usually larger. The metric is for choosing between vendors and for sizing the abstraction, not for refusing to buy.

Interview question

Q: You are signing a three-year contract for a critical platform capability. What do you insist on before signing, and how would you know two years in whether your position has weakened?

What a strong answer covers: estimate the exit in engineer-months and weeks now, and record it. Insist on continuous data export in a usable format rather than a contractual right to request it. Decide deliberately which vendor-specific features to use and put the rest behind an internal interface. Two years in, re-run the paper exit: if the number has grown, direct integrations have spread and the renewal will be priced accordingly. Start the alternative evaluation one renewal cycle early, because bargaining room is a function of the days remaining rather than of contract language.

Quick check

Quiz: Why is exit cost the number that decides a renewal price? — Because a vendor's pricing power is bounded by what it would cost the customer to leave, and an exit that cannot be executed within the notice period removes the alternative entirely.

Flashcard: What single practice does most to keep exit cost low? — Continuous export of your data into your own storage, plus keeping the vendor behind one internal interface, so leaving is a module change rather than a 40-service change with no history to bring along.