Your Moat Is Someone Else's API

You built an AI product. People use it. The numbers go up.

Then someone asks: how is this different from just using the model directly?

And you don't have a good answer.

Not because you didn't build anything. You built prompts, workflows, context management, eval harnesses, a UI people actually like. But none of that lives in the intelligence layer.

And the intelligence layer is rented.

---

What the business actually is

Strip the narrative away and most consumer AI startups today are doing the same thing: buying intelligence by the token and reselling it by the month.

You buy capability from a model vendor at metered rates, wrap it in a product, and charge a subscription. The spread is the business.

That's not an insult, it's a description. Plenty of good businesses are built on resale. But it has one structural property worth being honest about: the thing your product is actually made of doesn't belong to you.

---

What that costs you

Four consequences follow, and they compound.

Prices move, and your margin moves with them. Your unit economics are set by someone else's pricing page.

Behavior changes, and your product changes with it. A model update ships, your outputs shift, and you usually find out from users rather than from a changelog.

Your scenario can get absorbed. If what you do is valuable and general enough, there's a real chance the vendor ships it natively. At that point you're not competing on product, you're competing on still being necessary.

Your layer thins as the base model improves. This one is slower and easier to miss. A meaningful share of your prompt engineering, retry logic, format coercion, and orchestration scaffolding exists because the model can't do it reliably yet. Each generation absorbs some of it.

The "it's just a wrapper" criticism stings not because it's rude, but because it names something true:

How much value you hold is a function of what the model hasn't done yet.

---

"But we have user data"

The standard answer to the moat question is the data flywheel: more users → more data → better product → more users.

Under the constraint that you don't own a model, that flywheel mostly doesn't spin. It jams in three places.

1. You can't use the data

User data carries privacy obligations. Whether it can be used for training, how it gets de-identified, what your consent language actually covers — each is a real gate. Plenty of teams have the logs and can't get past legal.

2. Even if you can use it, there's nowhere to put it

You don't own a model. The data can go into prompts, into retrieval, into a thin adapter. It cannot go into the intelligence itself.

3. The quality isn't there

What actually improves a model is labeled, outcome-verified, feedback-carrying samples. What most applications accumulate is logs. Logs are excellent for analytics. They are not training data.

So for most application companies, "data flywheel" has been a story rather than a mechanism.

---

So why not train your own?

Two years ago this was a bad idea, for two solid reasons.

Open models were meaningfully behind. Building on one meant starting from a lower ceiling. You'd invest months and still ship something worse than a direct API call.

The base models were improving fast. Any domain advantage you spent six months building could be erased by the next general release. The ROI didn't close.

So "the application layer shouldn't touch models" became close to consensus. And at the time, that consensus was correct.

---

What changed

Two things, roughly at once.

Open models crossed into trillion-parameter territory, with substantially stronger coding and agentic capability. They handle genuinely complex long-horizon tasks now. On general capability the gap to the closed frontier has narrowed considerably.

Domain-targeted post-training became a real lever. In a specific domain, with the right data, there is now a chance of beating the closed SOTA model in that domain.

Read that carefully: a chance, not a certainty. I'm not claiming you will. I'm claiming it moved from "essentially impossible" to "possible" — and that shift is large enough to change a decision that was previously automatic.

---

"Owning" is a spectrum, not a binary

Worth being precise here, because "own your model" gets thrown around loosely and the levels have very different economics.

When I say "owning intelligence" in this post, I mean the third row. The first two are worth doing and often sufficient; they just don't buy you the thing this post is about.

---

What owning intelligence actually buys you

The first three rows are cost and risk management. The fourth is compounding, and it's the one that decides long-run separation. Owning a model is what finally gives your data somewhere to go.

---

Should you do this?

Six questions. Be honest on each.

• [ ] Is general-purpose capability clearly insufficient in your domain?
• [ ] Do you have data nobody else can get?
• [ ] Can that data legally be used for training?
• [ ] Is inference cost a material line item yet?
• [ ] Is latency central to the product experience?
• [ ] Can you staff and fund a post-training team?

4+ yes → worth seriously evaluating.
2–3 yes → try it on one narrow slice. Don't restructure the company around it.
0–1 yes → keep renting. That is the rational call, not the cowardly one.

This is a framing device, not a scorecard. Where you set the threshold depends on your runway and your window.

---

Three things that have to be said

1. This is not free.

Owning intelligence means a team that understands post-training, compute, a data pipeline, and eval infrastructure you trust. It also means accepting real risk that your iteration speed gets worse before it gets better. Those costs are not small, and they're mostly fixed.

2. Most companies should not do this.

If general models are good enough for your domain, if your volume is still small, if you have no proprietary data — renting is correct. Don't do this because it makes a better story for the next round.

3. This judgment will change again.

Once intelligence is cheap and ubiquitous, the application layer will grow new business models, and "owns a model" may stop being an interesting axis at all. I'd expect that to happen.

So I'm not going to tell you that you should.

The accurate statement is narrower:

For the first time, owning your intelligence is a real option rather than a wrong answer. It used to be a mistake. Now it's a calculation worth actually running.

---

What this post is and isn't

This is a judgment call, not a benchmark report.

I've deliberately included no scores. How far open models have come in your domain, and what post-training actually buys you on your data, are things you have to measure yourself. The general trend is real; the size of the effect is entirely domain-dependent. Don't take anyone's word for the magnitude — including mine.

If you disagree with the framing, I'd genuinely like to hear where. The weakest link in the argument is probably the claim that domain post-training can beat a closed frontier model in-domain — that's the part most sensitive to what "domain" means and how much data you actually have.

---

If you're building on rented intelligence right now: which row of that table hurts most?

• Cost — volume goes up and the economics stop working
• Control — you're one roadmap decision away from being redundant
• Flywheel — the data is piling up and there's nowhere for it to go

Curious whether the ordering matches what I'd expect. I'd guess control ranks higher than cost for most people, and that flywheel only ranks first for teams who've already tried and hit the wall.