AI Business Strategy

The rationale for AI companies to run owned models is misunderstood

By Tom Sheridan, VP, RTP Global

2026 is the year the cost of AI started to bite, and startups are feeling it first. Before now, the AI startup path to scale was relatively simple: build an AI product over the top of frontier models to circumvent massive training and inference infrastructure buildout costs. Balance the inference costs owed to those model providers out with growth (customer acquisition revenue).  

But that model was never built to last. Inference costs acted as a drag on growth no matter how fast. The drag got worse when products moved from chat to agents. An agent reads the repo, calls tools, checks its own work and retries. Same user action, an order of magnitude with more tokens. Nobody repriced. Seats stayed flat, cost per seat scaled with task complexity, and the heaviest users became the least profitable. Then the labs started building the same products as their customers, on a timetable set by their own IPO plans rather than by opportunity. 

This vulnerability is front of mind for AI founders. It’s why Base44, the vibe-coding platform owned by Wix, recently caught attention announcing it was rolling out its own AI model, Base1 – trained on tens of millions of real interactions on its platform. Its stated rationale was explicit: to “own the critical core” of its product, rather than build indefinitely on top of someone else’s model. Cursor has been doing something similar for longer, training its own Composer models on top of Moonshot’s open-weight Kimi checkpoints. The conventional framing is that owning your own model acts as a moat for AI startups.  

I’d be careful with that framing. Announcing loudly that your product isn’t a wrapper is a signal to the market, and signals to the market are cheap. A defensible position is a different thing, and founders need the second one far more than the first. 

No sudden realisation   

Observers misjudge how long this has been on founders’ minds. Frontier APIs are expensive and always have been, so startups with the engineering talent to do it have been fine-tuning open-weight bases, mostly Qwen and DeepSeek derivatives, and routing simple high-volume work to them. That workaround is years old, not a response to anything that happened this year.

What shifted is the second wave of Chinese open-weight releases. Moonshot’s Kimi K3 is the clearest case: 2.8 trillion parameters, weights public, top three on the major capability indices. Treating that as a fallback tier is wrong. But the gain isn’t cost. Most teams will consume K3 through an inference provider, which is still an API call to someone else’s GPU. The gain is leverage. When the weights are public nobody can reprice you or deprecate the model underneath you. That retires the same risk training your own model retires, at a fraction of the price. 

Cursor is the test case, because it did everything the moat argument recommends. It trained its own Composer models. It held outcome data no lab could see, covering which diffs were accepted, which tests passed and which sessions completed, and it wasn’t enough. It grew about as fast as any software company on record and turned down OpenAI twice. Then it agreed to sell to SpaceX for $60 billion, four days after SpaceX went public. 

The owned model wasn’t wasted. It cut what Cursor owed a frontier provider on the work Composer could handle. It did nothing about the work Composer couldn’t. What got Cursor wasn’t a capability gap. Revenue was still climbing. Its share of category spend fell from roughly 41% to 26% over twelve months while it paid retail API pricing on the remainder, to a competitor running wholesale economics on its own product. Which raises the real question: when is training your own model actually worth it? 

The real filter is the cost of being wrong  

The answer has most to do with consequence. The variable that matters is the cost of being wrong – specifically, how costly a bad output from your own model would actually be, given where you’re deploying it.  

For a vibe-coding platform, like Base44, a bad output is met with a fresh user prompt and a regenerated output; nobody is harmed, and the fix costs seconds. That’s precisely the low-stakes, high-volume, repetitive workload where a smaller, specialised model wins because being wrong is cheap.   

AI systems built for high-stakes workflows don’t enjoy the same kind of leeway. AI startups selling into law firms, banks or hospitals would think twice – not necessarily for lack of engineering capacity, but because a wrong output in a heavily regulated setting carries liability that dwarfs any cost saving.   

The question isn’t what training your own model would save you. It’s what a mistake would cost you.  

Volume is the wrong metric  

An owned model only makes sense for certain kinds of startups. Even there, the argument for it usually falls back on training data volume. Base44’s own announcement demonstrated that instinct perfectly: a press release touting a model trained on “tens of millions of real user interactions”. We’re back into the realm of market signals.  

The reason is that interaction data saturates quickly. A model needs only so many examples to learn the shape of a workload – the millionth similar example teaches it nothing the hundred-thousandth didn’t.  

The distinction that matters is between interaction data, what users ask for, and outcome data, what happened afterwards. Outcome data is what startups alone hold. 

  • A coding tool knows which of its diffs survived review and which tests passed after the change shipped 
  • A sales tool knows which drafted outreach got a reply and which deals closed 
  • A recruiting tool knows which candidates were placed and which were still there at twelve months[Text Wrapping Break] 

A foundation model provider sees interactions. What it never sees is what happened next. That asymmetry is real, and it’s also where the two filters collide. The cost-of-being-wrong test says build your own model where errors are cheap. The outcome-data test says the asset only exists where someone downstream records what happened. Those two conditions overlap less often than the moat argument assumes. The zone where owning a model genuinely defends you is narrow, and most companies claiming to be in it are not.  

A nuanced picture  

Startups training their own models aren’t necessarily building a moat. If owned models are designed to out-compete the frontier labs on raw capability, that fight isn’t winnable.   

Where the case gets stronger is when outcome data a foundation model provider can’t access is used to constantly fine-tune an owned model. 

I sit on boards where this comes up. It never starts as strategy. It starts when someone reads the gross margin line and sees it getting worse with scale. The owned-model plan arrives about a month later, and by then it’s being asked to fix something it can’t fix. 

Outcome data is necessary and not sufficient. The constraint isn’t whether you hold asymmetric signal, it’s whether you survive long enough for it to compound. That’s a balance sheet question, not a data question. Vertical integration on compute beats data asymmetry on a five year horizon, and almost no vertical AI startup is capitalised to test that. Most of them will try to fix the stack. The ones that survive will fix what they charge. 

Related Articles

Back to top button