Picture the email you don’t want to get. The AI tool your team has quietly built half its work around, the one your developers tuned their whole process to, the one a real part of your business now runs on, is changing. The price is tripling next quarter. Or the model you depend on is being retired in ninety days. Or the free tier you prototyped on is simply gone.
Here’s the part that turns a nuisance into a knot in your stomach: you can’t really say no. Your people have built so much around this one tool that leaving would cost more than staying and paying. You don’t own that process anymore. The vendor does. You just haven’t gotten the invoice that proves it yet.
I’ve seen this movie before. And it starts with a story you already know, even though I’m not going to name anyone.
Once there was a beloved company. Its name quietly became a verb for finding things on the internet. It made a browser that was actually faster than the one we’d all been suffering through, and we were grateful. For developers like me, it handed out a box of free toys: maps you could drop into your own app, search you could bolt onto your own store, clever little tools for almost anything. And we loved them for it. We trusted them. Nobody in that era had lived through this before, and there was no gray-haired advisor in the room telling us to be careful, so we did the natural thing. We built real things on top of their toys and assumed they’d always be there. It felt like a gift.
Then, one by one, the toys went back in the box. Moving fast and beloved for it, the company changed things out from under people, retired products with real users, and quietly shut down tools that developers had wired into their livelihoods. This wasn’t malice. It’s just what a fast-moving company does. There’s a public memorial site to this day, kept by developers, listing everything this one company has killed. It runs to nearly 300 products, and the average one lived about five years. Long enough to build your business on. Short enough to lose it without warning.
I lived that era as a developer. I built on those toys, I trusted they’d last, and I watched some of them vanish under things I’d already shipped. Back then it stung but it was survivable. It was one company, the tools were simpler, and re-engineering around a dead API was a rough few weeks, not a catastrophe. Nobody had warned me, because back then nobody knew to. It taught me a lesson I’ve carried into every project since: the company you love will still change the terms, and being early and trusting is exactly how you get caught.
Now take that lesson and make it bigger in two ways. It isn’t one beloved company anymore. It’s hundreds of AI providers, and most of them will not exist in a few years. And what you’re building on them isn’t a widget on a webpage. It’s a core business process. Same mistake, far higher stakes.
We’re not even early enough for this to be theoretical. There’s already a public graveyard for dead AI products, the same way there is for that old company’s, and it passed ninety entries this year. Deprecated models. Shut-down tools. Failed startups. One popular AI product was retired and its users lost work they’d created on it, overnight. This is happening now, at the very start of the curve.
The risk comes in three flavors, and they get quieter and more certain as they go.
The first is the obvious one. The startup vanishes. If a piece of your business runs on a company that doesn’t survive, it leaves when they leave. And don’t assume this is someone else’s problem because you’d only ever pick a big name. Plenty of businesses are quietly depending on a small AI startup right now, sometimes without leadership even knowing which one, and that’s exactly the dependency most likely to disappear.
The second is the one the old company taught us. The survivor deprecates. Even a thriving provider retires models and kills features on its own schedule, not yours. Surviving the vendor is not the same as surviving the dependency. The company from the top of this story never died. It still took the toys back.
The third is the quiet one, and it’s the one that belongs in a boardroom. The winner reprices. It’s an old play: get everyone built in while it’s cheap, sometimes even free, wait until leaving means a rebuild, then charge what the lock-in is worth. You can already see the terms shifting. Free tiers are being monetized, and the models developers build on get retired on the vendor’s timeline, not yours.* Your leverage as a customer is highest before you build and lowest after. And when your team has tuned everything to one provider, the cost of the price going up and the cost of walking away become the same wall. That’s not an IT footnote. That’s a business-critical cost increase you’d have no power to refuse.
Three flavors, one disease: letting a single provider become load-bearing in your business.
The cure is the same for all three, and it has less to do with which AI you pick than with how you build on it. Don’t let any one provider hold up the roof. Put a layer of your own between your business and the model, so swapping one out is a configuration change, not a rebuild. Own your data and your logic. Rent the model. Decide how you’d leave before you build the thing you’d have to leave. Design for portability on day one, so you always keep the leverage to walk.
This isn’t theory for me. It’s the discipline I bring to every engagement. I make sure the model stays swappable from day one, so the business logic never rides on any single vendor’s roadmap. When one changes its terms, and one always does, it’s a config change and a quiet Tuesday, not a crisis.
None of this is an argument against AI. Adopt it, aggressively even. It’s an argument against building so carelessly that a vendor’s roadmap quietly becomes your roadmap. The failures here, like most technology failures, won’t come from the technology. They’ll come from how carelessly we let ourselves depend on it. And the leaders approving these projects almost never see the lock-in their teams are creating underneath them, which is exactly the gap between the business and IT that decides how this goes.
So before you approve the next AI build, ask one question. What would it cost us to leave? If nobody in the room can answer, you haven’t bought a capability. You’ve rented one, and you don’t own the process it runs. The vendor does.
*This is already visible. Providers routinely retire the models developers build on, forcing migration on the vendor’s timeline rather than yours (OpenAI has moved GPT-4 and GPT-4o to legacy), and previously free tiers have added ads and paid limits. OpenAI’s own product lead has said publicly that its pricing will “significantly evolve.”
