What Happens When Your AI Vendor Disappears

Lock-in in AI systems is not a technology question. It is a decision made at purchase.
Three questions decide whether losing a vendor means a migration or a rebuild from zero: Does the stack run in your own cloud account, or the vendor’s? Does your company own the source code under a perpetual license, or only a license to access it? Can the underlying AI model be swapped, or is the workflow hard-wired to one vendor? Answer these three questions before you buy, and you buy independence along with the product.

On May 20, 2025, Builder.ai announced its insolvency. At its peak, two years earlier, the company had been valued at well over a billion dollars. Microsoft was among its investors, and the core pitch was: an AI called Natasha builds software with almost no human developers. In reality, humans wrote most of the code by hand: in-house developers and outsourced ones, in India, Ukraine and elsewhere. The Wall Street Journal had reported as much back in 2019. In the months before the insolvency, the company had cut around 270 jobs.

For every company that had Builder.ai build an application for them, that day turned a question that had been theoretical into a real one: Does the system keep running? Who maintains it now? And do we actually own any of it?

Builder.ai is the most prominent case so far, because a global tech company had invested and the valuation was so high. Smaller AI vendors disappear more often, just without the headlines. The question applies to any external AI system, a ready-made platform as much as a custom build.

What vendor lock-in means for AI systems

Lock-in means a company cannot switch, take with them, or keep running a system without major effort, because it is technically or contractually tied to a single vendor. In classic software, that is an old problem. AI systems add another layer: beyond the application itself, the model behind it is often tied to exactly one vendor too, through its own, usually proprietary interface.

Lock-in is not a law of nature. It is the result of three decisions made at the point of purchase or when a contract is signed, usually without anyone noticing they were decisions at all.

Question 1: Where does the stack run?

If the application runs on the vendor’s infrastructure, the vendor owns the operation, no matter what the contract says about the code. If the vendor goes down, the server goes down with it. If the same application runs in your own cloud account instead, with your own credentials and your own billing, it stays reachable even if the vendor who built it no longer exists tomorrow. The difference is not in the code. It is in who gets the server bill and who holds the credentials.

Question 2: Who owns the code?

A software-as-a-service license grants access, not ownership. When the contract ends or the vendor does, access ends too, usually without anything being physically handed over. A work-for-hire contract that delivers source code under a perpetual, irrevocable license transfers something that stays: a copy that sits in your own repository, regardless of what happens to the vendor. That difference gets decided before signing, in a single contract line that rarely gets negotiated, because nobody plans a project expecting the vendor to fail.

Question 3: Can the model be swapped?

The third layer is not about the application, it is about the AI model behind it. If the code calls a model API hard-wired in, with vendor-specific parameters scattered through the application logic, switching models means a rebuild. If the same call instead goes through your own stable interface, behind which the actual model in use can be swapped, that same switch becomes a configuration change. The difference usually only shows up once a switch is actually needed, too late to retrofit cheaply.

For the technical depth

All three questions point to the same answer: an abstraction layer between the application and everything that belongs to a vendor. Infrastructure as code (Terraform, CloudFormation, or similar) in your own cloud account makes operations reproducible, regardless of who originally set it up. A gateway or router in front of the model calls exposes your own stable interface and talks to whichever model sits behind it through that model’s own API. A model switch then becomes a single endpoint URL you change, not a search-and-replace across the entire codebase. Both are design decisions made at the start of a project. Retrofitting such a layer later is almost always possible, just more expensive than planning for it from day one.

Owning the code is not automatically independence

Owning the source code alone does not solve the problem. A company that has the complete code but nobody who understands it has traded one dependency for another: the external vendor for a single person or a single internal team. That team’s departure hurts just as much as a vendor’s insolvency. Documentation, a second point of contact, and a realistic handover plan belong to independence just as much as the contract clause does. And even with your own stack, your own code, and a swappable model, some switching cost remains: a new team has to get up to speed, a new model never behaves exactly like the old one, and any migration takes time. The difference is not zero cost against total loss, it is weeks against months, and a restart with your own data instead of none at all.

What this means for choosing a vendor

The three questions can be asked before signing any contract, for a ready-made platform as much as for a custom build or an internal project with outside help. Where does operation run, who ends up owning the code, and how much work would a model switch actually be. Push a vendor for concrete answers instead of general assurances, and the hesitation itself usually shows which of the three questions their offer never accounted for.

You can now ask any AI vendor who walks through the door the same three questions that still matter after the contract is signed. If you already look closely at the license model, as in the previous post in this series on the gap between paid and used Copilot seats, look just as closely at the vendor itself. How large the quality gap between swappable open models and the big, familiar vendors actually is, honestly quantified, is the topic of the next post.

Frequently asked questions

What does vendor lock-in mean for AI systems? Vendor lock-in means a company cannot switch, take with them, or keep running an AI system without major effort, because it is technically or contractually tied to a single vendor. It comes down to three decisions: where the stack runs, who owns the code, and whether the underlying model can be swapped out.

How do you protect a company contractually against an AI vendor disappearing? The core is ownership, not access: source code as a delivered asset under a perpetual, irrevocable license, operation in your own cloud account rather than the vendor’s, and an architecture that keeps the AI model swappable instead of hard-wiring it in. These three points belong in the contract before signing, not after.

Is owning the source code enough to avoid lock-in? Not on its own. Without in-house knowledge of how to run and maintain the system, a dependency remains, just on one person or one internal team instead of an external vendor. Owning the source code lowers the risk of total loss, but it does not replace the ability to actually operate the system.

Sources

Builder.ai announces insolvency (May 20, 2025): The Register, mlq.ai.
Valuation over a billion dollars, Microsoft as investor: TechCrunch, Tech Startups.
Human developers instead of the advertised AI (Wall Street Journal, 2019); around 270 jobs cut in March 2025: Rest of World, The Register.
The viral post-insolvency claim that 700 engineers had merely faked the AI did not survive technical scrutiny: The Pragmatic Engineer.