On Monday it was the best model on the market. By Thursday it was gone.
Recently one of the strongest AI models was pulled from public access just days after its launch, by order of a regulator. Not only for new customers. For everyone. Companies that had already embedded the model in their product and were paying for it woke up to a process that had simply stopped existing.
I won't comment on which model it was, why it was shut down, or whether that was the right call. That's someone else's problem. Mine is closer to home: how many of the processes we build for our clients would survive to Friday if their provider vanished on Monday?
I suspect the honest answer in quite a few teams is "we don't know." And that, already, is the answer.
The Uncomfortable Question
There's a moment in the life of every technical team when someone asks the uncomfortable question. "And what if this provider shuts down tomorrow?" And there's almost always someone else who rolls their eyes. Why complicate things. It works. It's fast. It's cheap. Why maintain an abstraction, a second layer, a fallback path, when this one never goes down.
This one always goes down. Not necessarily because it's bad — a regulator can shut it off, it can change its terms, triple its price, or simply have a bad day at the worst possible moment. The question is never whether, but when. And how much it will hurt when it does.
The maturity of a team isn't measured by how fast it embeds the newest model. It's measured by how calmly it could take it out.
The maturity of a team isn't measured by how fast it embeds the newest model. It's measured by how calmly it could take it out.
The Model Is a Replaceable Part, Not a Foundation
When we put AI at the core of a business process, we start from one assumption: the model we use today will not be the model we use a year from now. It may be better. It may be gone. In either case, swapping it should not be a project — it should be a configuration change.
In practice this means a few boring things that are worth it:
We don't hard-wire a single model ID deep into the code in ten places. We route through an abstraction layer — a gateway — so that switching providers is a change in settings, not a migration.
We have a fallback model that is defined and tested, not theoretical. "We'll figure it out if we have to" is not a plan. A plan is the one you've already rehearsed on a Friday afternoon, when nothing is on fire.
We know which processes are critical and which are nice to have. Not everything deserves redundancy. But the critical ones get it before they ask for it.
This costs a little more up front. The alternative costs dearly — and always on the most inconvenient day.
Half a Day of Insurance
A colleague once spent half a day making it so we could switch the model provider with a single change. At the time it struck me as overkill. We had more important things to do. He did it anyway.
Months later, when exactly that happened on the market — a model disappeared in days — that half a day turned out to be the cheapest insurance we'd ever paid for. While other teams were writing crisis emails to their clients, we changed one line and moved on.
I'm not telling this to brag. I'm telling it because at the moment he was doing it, it looked like wasted time. That's exactly what good engineering looks like right before it's needed: like excessive caution.
What Trusted Advisor Actually Means
Being a trusted advisor doesn't mean picking the best model today. Anyone who reads the headlines can do that. It means designing a system that survives the day the best model disappears — without the client even noticing.
A single point of failure doesn't ask for permission. It just waits. Our job is not to leave it alone.
This week I relearned something I already knew: the questions that sound paranoid on Monday are usually the most important ones by Friday. We hire the people who ask them on time, before they turn into emergencies. If that sounds like you, [see our open roles].