AI vendor lock-in: measure your exit in days before you sign

AI vendor lock-in is measured in days-to-switch, not in price per token. The two architecture paths, what each costs, and the exit test you can run in one afternoon.

Counting how many files reference the vendor SDK takes one afternoon and beats any price-per-token table

Before you let an AI vendor sit on your product's critical path, measure one thing: how many days your team needs to rip that vendor out and drop a different one in, with the product still up and customers noticing nothing. That number is your AI vendor lock-in, and it was already decided before the first API call went out.

There are two common answers. In the first, the model call is scattered across the codebase, tangled into business rules, with the vendor's response shape leaking into your database and your UI. Swapping that is a project. In the rescue work that lands on my desk, the pattern is roughly 11 call sites, two of them somewhere nobody remembered, and the swap turns into about six weeks of work plus regression testing on things that already worked.

In the second, the call lives behind a boundary you own: one interface with two or three methods the rest of the system knows about, and nothing else. Swapping that is a two to four day task, plus the time to compare output quality. The boundary charges you up front, somewhere between two and five engineering days on the first implementation, and it is the cheapest line item in the build.

Think of a pipe cast into the concrete slab versus a pipe running through an access shaft. Both move water exactly the same way, every day, right up to the day you have to replace one. Then one costs a wrench and the other costs breaking concrete.

CIO ran a piece yesterday about the day your AI vendor shuts down or gets acquired, and it points at Broadcom's acquisition of VMware as the picture of what is at stake: the product keeps existing, the deal you signed does not. Your vendor might outlive all of us. The problem is that you do not know the number of days, and whoever does not know the number accepts whatever renewal price shows up.

Days-to-switch is the number you bring to the renewal call

A pipe in an access shaft costs a bit more to install and one wrench on replacement day

Price per million tokens moves every quarter and protects nobody. The number that protects you is your exit time, and it does work in three different rooms: contract renewal, investor diligence, and the meeting where someone proposes using the same vendor for one more feature.

Once exit time is measured, the renewal conversation flips. At three days of exit, an aggressive price increase is the vendor's problem. At six weeks, it is yours, and they usually know that before you do.

It pays off in the happy case too, which is the frequent one. A new model lands every few months, cheaper or better at one specific task. Teams with a boundary test it over a weekend. The growth orchestrator I write for fun has changed models more than once this year, and each swap took an afternoon, because nothing downstream ever knew which vendor sat behind the interface.

Slab or shaft: where the model call actually lives

A boundary here does not mean a generic abstraction layer with fifteen parameters built to cover every vendor on earth. It is one interface written in your business vocabulary: classify the order, extract the invoice fields, summarize the contract. What goes in and comes out are your own types, validated at the door. The vendor's raw JSON dies inside that file.

Three things stay on your side of the door, and they are what pulls the timeline down. The prompt in a versioned file, with history of who changed what and why. Validation of the response, because a new model breaks format in new ways and you want to find that in CI, not in a customer's account. And a log of input and output for every call, which is the only way to compare the new vendor against the old one without a room full of opinions.

The failure I see most has to do with who wrote the integration. A coding agent writes the shortest possible version, and the shortest version calls the SDK straight from inside the service, model name hardcoded mid-file. Nobody reviewing for that means the technical debt an agent leaves behind shows up on the exact day you need speed to get out.

The exit test, run in one afternoon

Exit time belongs in writing before signature, not discovered during the renewal call

1. Count how many files reference the vendor's SDK. If that number is larger than the number of use cases it serves, you already know your timeline.
2. Search your database for their shapes: response ids, message structures, model names stored in columns. Every hit is a data migration on swap day, and data migrations do not fit in an afternoon.
3. Try to point at the file holding the prompt within ten seconds. If prompts live as strings inside a service, somebody will be rewriting prompts under pressure with the vendor already dark.
4. Ask who has run the same use case through a second vendor, and where that comparison is saved. Without that file, switching stops being engineering and becomes a bet.

Write down all four answers and convert them into working days for the team you have now, not the team on the hiring plan. That is your cost of exit. Store it next to the contract, because that is where someone will look the morning the news breaks. If you want a faster read on the vendor itself, the 30-minute audit covers the other half of the question.

"That's architecture theater, I need to ship in three weeks"

I partly agree, and it is worth saying out loud: for a three week validation that may be dead next month, a boundary is cost with no return. Embed it, ship it, find out whether anyone pays. I would do the same.

What does not work is "we'll clean it up later" with no written trigger. My trigger is plain: the day that feature enters a flow a customer pays for, or starts running without a human watching, the boundary goes in before the next feature. Same logic as migrating a bit per sprint instead of stopping everything. The work is nearly identical, the price is not, once the deadline is already on fire.

There is also the pre-signature conversation, where this costs nothing. If you are hiring an agency or a contractor to build the integration, add one question to the list: where in the code does the vendor call live, and what exactly do I replace if they disappear. The answer arrives immediately or it does not arrive. While we are on contractors, check whether your last vendor is still logged into production too, since that is the same question asked about access instead of code.

The part you cannot isolate

A boundary moves the swap from project to task, never to zero, and anyone promising zero is selling. Three things stay on their side:

• The prompt tuned to how that specific model answers, which behaves differently on a competitor and needs tuning all over again.
• Whatever got trained or indexed in their house: fine-tunes, vector stores, conversation history, accumulated evaluations.
• The latency and context window you quietly used as a product assumption, which the next one may not match.

You can shrink all three with boring discipline. Export rights for your own data written into the contract, in an open format, with a deadline in days. Your own evaluation set stored outside the vendor, because a green dashboard that never compares output guarantees nothing. Thirty real cases with expected answers will tell you in one afternoon whether the new vendor works for your problem or only for its own benchmark.

The number you can say out loud

Answer without checking with anyone: if your AI vendor announced today that it shuts down in 30 days, which part of your product stops working, and how many days until you are back up? If the answer starts with "let me ask the team," the risk is not on the vendor's balance sheet. It is in your repo.

Count the call sites today. One afternoon, one number. Then choose on purpose: slab or shaft. Both choices hold up in a board meeting, as long as the choice is yours and it is written down before the news breaks.