Your AI Moat Is Not the Model

Every company I talk to is asking the same question: which AI model should we build on? It feels like the decision of the decade. Get it right and you are ahead for years. Get it wrong and you have bet the business on the losing horse.

It is the wrong question, and the anxiety around it is the tell.

After 35+ years in software and security, and as someone who acts as the CTO for three companies I own, I can tell you the model is one of the least durable decisions you will make. The thing that will decide whether AI actually grows your business is what you build around it.

The frontier is a commodity in slow motion

Look at the last three years honestly. The leading model has changed hands repeatedly. Capabilities that were a moat in the spring were table stakes by the fall, available to anyone with a credit card and an afternoon. Prices have fallen off a cliff. This is not a market that rewards loyalty.

Whatever edge one model has this quarter, another has next quarter. And your competitor can rent the exact same one you did.

So if the model is not defensible, what is?

What you build around the model

The companies actually getting returns from AI are not the ones who picked correctly. They are the ones who built something that stays valuable no matter who wins the model race:

• Your data, and the pipes that keep it clean. No model rescues bad inputs. The unglamorous work of getting your data accurate, current, and reachable pays off with every model you will ever use.
• The workflow wrapped around the output. Raw model output is not a product. The review step, the escalation path, the place a human confirms before anything irreversible happens, that is what makes AI trustworthy enough to actually deploy.
• An evaluation harness. If you cannot measure quality, you cannot detect it slipping, and you certainly cannot compare a challenger model against your incumbent. Evals are how a swap becomes a measurement instead of a leap of faith.
• The constraints. This is where experience earns its keep. At a sports video company, we built AI to find marketable moments using facial recognition. Run against every player in the league, it produced garbage, including once tagging a player who had been dead for twenty years. The fix was not more AI. It was constraint: limit recognition to the 22 players actually on the pitch. Accuracy soared. The value came from knowing where to fence the model in.
• The judgment about where AI does not belong. Knowing which problems to point AI at, and which to leave to people, is a decision no model makes for you.

Notice that none of that is the model. And all of it survives when you replace the model.

The bill nobody prices in

Here is the uncomfortable part. Most teams could not switch models today even if a clearly better one shipped tomorrow.

They see the per-token price when they choose. They do not see the prompts painstakingly tuned to one model's personality. The evals written against its particular output shape. The team that only knows one SDK. The features quietly designed around what that model happens to be good at. The vendor-specific calls scattered through the codebase.

None of that appears in the vendor comparison. All of it appears the day you try to leave.

That is switching cost, and it is the real lock-in. Not a contract. Accumulated architectural debt that nobody chose deliberately. The expensive dependency is never the one you decided on. It is the ten you absorbed by accident.

Treat AI as a swappable tool

The discipline here is old, and it is not exotic. You put an interface between your business logic and the component you know will change. We have done this with databases, payment processors, cloud providers, and message queues for decades. An AI model deserves exactly the same treatment, and for exactly the same reason: it will be replaced.

In practice that means a few concrete things. Route every model call through one internal layer instead of scattering vendor SDKs across your app. Keep prompts as versioned configuration, not as strings buried in code. Maintain an eval set that any candidate model must pass, so a swap is an afternoon of testing rather than a quarter of rework. Design features around a capability, like "summarize this document reliably," rather than around a specific model's idiosyncrasies.

Do that, and the question "should we move to the new model?" becomes a routine engineering decision with a measurable answer, instead of an existential one.

In my own companies I assume every model I use gets replaced, because so far every one of them has been. Building for that assumption has never cost me much, and it has saved me a great deal.

Where does AI fit in your business?

This is the part a fractional CTO or AI advisor should be pushing you on, and the part most AI consultants skip because model selection makes for a better slide. Which problems genuinely deserve AI. What has to be true for the output to be trusted. What it would cost you to be wrong. Whether the thing you are building still has value when the model underneath it is obsolete.

AI is not the whole solution. It is a genuinely powerful component, and the winners are the ones who understand its limits well enough to build something beautiful that incorporates it, rather than forcing it to be the entire product.

Build for the swap. It is coming either way.

If you want a clear-eyed read on where AI actually fits in your business, and where it does not, I take a few clients at a time. Book your AI Fit Call →