Vendor Reversal Cost
also called Buy Unwind Cost, Vendor Disentanglement Estimate
The engineer-months needed to unwind a buy decision - dominated by business logic that leaked into the vendor's configuration rather than by anything the contract's termination clause covers.
A company buys a fraud-decisioning product in 2021 rather than building one. By 2024 it wants out. Procurement produces the contract: 90 days' notice, documented data return, no fee. The exit looks cheap.
Then someone opens the vendor's console and counts 1,400 configured rules, 60 scoring thresholds per market and a dozen workflows that encode how this business decides what fraud is. None of it exists in the company's repository. The exit is not a procurement exercise, it is a re-implementation of an undocumented system, and the estimate arrives three months into a programme scoped on the contract.
Vendor reversal cost is that estimate, made at purchase time instead of exit time, in engineer-months.
Why it matters
Build-versus-buy is routinely decided on a three-year cost comparison in which buy wins because it has no build line. The comparison is incomplete without the cost of being wrong, and buy decisions are wrong often enough to matter: vendors are acquired, reprice, or stop keeping pace.
It matters more because the cost is controllable at purchase and almost uncontrollable later. The decision that sets it — whether your rules live in your repository or their console — is made in the first implementation sprint. A choice nobody treated as architectural sets the price of reversal for a decade.
Implementation patterns
- Four lines, estimated at purchase in engineer-months: re-implementation of configured logic; data extraction and reshaping; the dual-run; re-integration of every consumer.
- Count the configured artefacts quarterly — rules, templates, workflows, custom fields. A rising count is the reversal cost growing, the cheapest leading indicator there is.
- Keep rules in your repository and treat the vendor as an execution engine, pushing configuration from version control rather than editing in their console. The most effective cap, and roughly free if done from the start.
- Enumerate consumers in a register: webhook subscribers, reports, pipelines, the finance spreadsheet. A five-year-old integration commonly has 20 to 40.
- Budget the dual-run: one to two quarters of both systems live, two licences, one named owner.
Industry example
A European lender buys a decisioning platform for consumer credit. Over four years the credit-risk team, who are not engineers, build policy inside the vendor's rule editor, because that is what the product is for and because it ships a change in a day rather than a sprint. By the time the lender wants to move, the only complete specification of its credit policy is a database it does not own.
The unwind is quoted at 14 engineer-months and lands at 31, the overrun almost entirely in reconstructing rule semantics never written down. Dual-run takes two quarters because the regulator requires evidence that decisions match. The contract's exit clause was honoured in full and was irrelevant to the cost.
Failure scenarios
- Exit scoped on the contract, so the programme is funded on the small part and stalls.
- Configuration as shadow source code, with no tests, review or history, so reconstruction means reverse-engineering behaviour from outcomes.
- Dual-run with no reconciliation owner, so divergence accumulates until cutover.
- The forgotten consumer: a quarterly report fails two months after cutover.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Rules in your repository | Reversal capped; policy version-controlled and testable | Business users lose same-day self-service; changes need a deployment |
| Rules in their console | Fast iteration by non-engineers | Reversal compounds quarterly; policy exists only in their system |
| Abstraction over their API | A swappable integration surface | Tracks the lowest common denominator and costs real upkeep |
The abstraction layer is chosen most and justified least: it protects the integration surface, which is cheap, and leaves the configured logic, which is expensive.
When not to use it
For a genuine commodity you will never leave. Payroll, email delivery and identity providers are bought so they stop being your problem; estimating an unwind you will not perform is theatre.
When speed is the entire point. A startup proving a market should buy, configure in the console and accept the lock-in, writing the decision down as deliberate.
When configurability is the value you bought. Forcing it into your repository removes the capability you paid for; price the reversal cost into the renewal instead.
Interview question
Q: You are buying a workflow product to replace an internal system. Finance has a three-year comparison showing buy wins by 40%. What would you add to the analysis, and what would you change about the first implementation sprint?
What a strong answer covers: that the comparison lacks the cost of being wrong, with re-implementation of configured logic as the largest of its four components; that the first sprint sets the reversal cost by deciding where rules live; the cap (configuration from version control, a quarterly artefact count, a consumer register); and when accepting lock-in is the right deliberate choice.
Quick check
Quiz: Which component dominates the cost of reversing a buy, and what caps it at purchase time? Re-implementing business logic that leaked into vendor configuration; keeping rules in your own repository and pushing them from version control.
Flashcard: Name the four components of a vendor reversal cost. — Re-implementation of configured logic; data extraction and reshaping; the dual-run with reconciliation; re-integration of every consumer. The contract's exit clause covers none of them.