Why We Built Our Own AI Layer Instead of Depending on OpenAI or Vertex

By Aaron Gammon · Founder, Inferrex · June 2026

This is the strategic companion to my more technical piece on building a self-sovereign AI training loop. That one is about how we improve our own models; this one is about why we own them at all, when wiring in a frontier API would have been so much faster. It's a decision a lot of people are weighing right now, so I want to lay out the reasoning plainly.

Where it touches what Inferrex does, I keep to outcomes, not methods. Live figures, including model status, at inferrex.com/claims.

The default move, if you're building an AI-powered product today, is obvious and well-trodden: pick a frontier model — OpenAI, Vertex, one of the big providers — wire in their API, and ship. You get state-of-the-art capability immediately, no model training, no ML team, no infrastructure. For getting to a demo, it's unbeatable, and I don't blame anyone who takes it.

The catch is that this isn't a one-time convenience. It's a permanent architectural decision, made quietly, that's very hard to reverse once your product is built on top of it. You haven't just used a frontier model to get started; you've made a frontier provider a permanent input to your product — and you've signed up for a bill that doesn't arrive until later, by which point unwinding it means rebuilding your deepest layer.

I'll lay out what's actually in that bill, because it's not obvious up front, which is exactly what makes it dangerous.

Wire in a frontier API and you inherit three dependencies, all at once, all permanent until you do the hard work of removing them.

Price. You're now exposed to someone else's pricing, which you don't control and which is set to optimise their business, not yours. Every inference your product runs is a cost denominated in their terms. As you scale, that's a margin you've handed to a supplier — and a number that can move under you with a pricing change you don't get a vote on.

Availability. Your product is now only as reliable as their API. Their outage is your outage. Their rate limit is your ceiling. Their deprecation of a model is your forced migration. You've coupled your uptime and your roadmap to a system you can't see inside and can't control.

Terms. You're bound by their usage policies, their data handling, their changes to what's permitted — and those can shift in ways that affect what your product is even allowed to do. You're building on rented land, and the landlord can change the lease.

None of these is fatal on its own, and for many products they're acceptable trade-offs. But they're real, they compound as you grow, and they're all consequences of the same root fact: the intelligence at the core of your product isn't yours.

The three dependencies are the costs you can live with if you choose to. This next one isn't a cost — it's a wall, and for the customers I care most about, it's the end of the conversation.

You cannot air-gap a product that has to call out to a cloud model. Full stop. If your intelligence lives in someone else's cloud and your product reaches it over the internet, then your product fundamentally cannot run in an environment with no internet. There's no clever workaround, no degraded mode that preserves the capability — the brain is in another building, and a sovereign or air-gapped customer has, by definition, cut the line to that building.

This matters because the most serious buyers in regulated, defence, and government markets require exactly that isolation. For them, "calls out to a frontier model" isn't a minor architectural detail; it's disqualifying. So the easy path doesn't just add three dependencies — it permanently forecloses an entire class of the most valuable, most defensible customers there are. You can't sell sovereignty on top of a rented brain. I make the full version of that argument in the sovereign-infrastructure pillar and the air-gapped piece; here it's the single decisive reason we own the layer.

So we built our own models. It was much harder, and here's what the hard work buys.

It runs anywhere. Because the intelligence is ours and local, it goes wherever the deployment goes — cloud, VPC, sovereign, fully air-gapped — with no external call required. The sovereign wall isn't a wall for us, because there's nothing on the other side of it we need to reach.

It costs what we control. Our inference economics are ours. There's no per-call margin handed to a supplier, no exposure to someone else's pricing decision. That control compounds in our favour as we scale, exactly where the rented model compounds against you.

It improves on our terms. Our models get better through our own closed loop — our corpus and human corrections — rather than being capped at "slightly worse than whatever we distilled from." We own our ceiling. (That's the subject of the self-sovereign training piece; the relevant point here is that ownership of the layer is what makes ownership of the improvement possible.)

And there's a quieter benefit: a specialised model, built for the bounded domain of understanding business APIs, can outperform a general-purpose frontier model on that specific task at a fraction of the cost — so owning the layer isn't even a capability sacrifice for our domain. It's better and ours.

I want to be careful not to overstate this into ideology, because the honest position is more pragmatic than "never touch an external model."

External models still have a place in the architecture — as an optional component, never a dependency. In the cloud tier, an external provider can serve as a fallback for a layer that isn't yet promoted on our own stack, or as a customer-chosen add-on for those who want it. The distinction that matters is the one between optional and load-bearing: an external model the product can use but doesn't need is a feature; an external model the product can't function without is a dependency. We built everything so the external model is always the former and never the latter.

That's the pragmatic line. Own the core intelligence so the product runs anywhere on its own terms; allow external models as an optional extra for those who want them; never let the product's ability to function rest on a call leaving the box. You get the best of both — frontier capability available where it helps, zero dependence on it where it would hurt.

The easy path was genuinely tempting, and for a different product I might have taken it. But Inferrex's whole reason to exist is to be the integration layer that serious, regulated, sovereign organisations can actually depend on and run inside their own walls — and you simply cannot build that on rented intelligence. The decision made itself once I was honest about who the most important customers were.

So we did the hard thing and built the layer. It cost more time and more effort up front, and it bought independence, economics, and a ceiling we own — and, decisively, the ability to run where the rented brain can never go. For a product meant to be infrastructure, that wasn't really a choice at all.