The four layers of an AI-native product, and the only one that's a moat

Every AI product demo I sat through last year showed me the same thing at the same moment. Somebody types a question, the model writes a good answer, everyone nods.

That demo costs about a weekend to build now. Which is a problem if it's also your company.

We mapped our own product as four layers when we were rebuilding, mostly so we could argue about where to spend engineering time. It turned out to be the most useful thing we did that quarter, so here it is.

The four layers

Data. Everything the system knows. Tickets, conversations, docs, product events, billing state, CRM records, the stuff sitting in Stripe and HubSpot and Linear that nobody has ever joined together.

Context. How you assemble the right slice of that data at the moment a decision gets made. Retrieval, ranking, memory, what you show the model and what you leave out.

Model. The reasoning. Which model, which prompts, which tools it can call, how you evaluate it.

Outcomes. What the system is actually allowed to do, and how you know it worked. Resolved the ticket. Flagged the churn risk. Drafted the reply. Escalated to a person.

Four layers, and about 90% of the AI conversation in b2b saas is happening in one of them.

The model layer is rented

Everyone is competing on the model. It's the layer with the announcements and the benchmarks and the launch videos.

It's also the layer you don't own. You're calling the same handful of providers as your competitor. If a better model ships on a Tuesday you both get it on the Tuesday. Any advantage you build there has a shelf life measured in weeks, and the price of that layer is falling fast enough that whatever margin you're protecting today isn't the margin you'll have next year.

Prompts are not a moat. Neither is your eval harness, though it will save you a lot of pain. Both are things a competent team rebuilds in a month.

I say this as someone who spent real money learning it. We had good prompts before we had a good product. The prompts were not the reason anything worked.

Context is where the work is

Context is genuinely hard and genuinely underrated. Deciding what the model should see at the moment it acts is most of the difference between a system that feels smart and one that feels like a search box with good manners.

But context engineering is a skill, and skills spread. The techniques we were proud of in early 2025 are in blog posts now. Assume anything you figure out here becomes industry standard in about 18 months, because it will.

Worth investing in. Not worth confusing with a moat.

Outcomes are pricing, not architecture

The outcomes layer is where you decide what the system is responsible for, and it's the layer most legacy vendors can't reach at all. If your product is built around a human clicking a button, you can't sell an outcome, because you were never the one producing it.

We built our pricing here on purpose. $0 per seat, $0.50 per resolved ticket. We only bill when something actually got done, and spam and no-touch tickets don't count.

That's a strong position commercially. It is not a technical moat. Someone can copy the price list this afternoon. What they can't copy is being able to afford it, which comes back down the stack.

The data layer is the only one that compounds

Which leaves data. The boring one.

Nobody demos the data layer. There's nothing to look at. But it's the only layer where the thing you build in year 1 is worth more in year 3, and it's the only layer your competitor cannot buy, rent, or reimplement from a blog post.

Here's what I mean concretely. When a customer connects Helply to their Slack, HubSpot, Stripe, Linear, Attio and GitHub, and we've ingested their full support history, the system knows things no model can reason its way to. That this account downgraded 6 weeks ago. That the bug they're writing in about has an open Linear ticket assigned to an engineer. That the last 4 people who asked this exact question churned within 90 days.

A better model on worse data loses to a worse model on better data, every time, in a support context. We tested this more than once, usually by accident.

And it compounds in the ugly, unglamorous way that real moats do. Every month a customer runs on the system, the system gets more specifically useful to that customer and harder to leave. Not because we locked anything, but because a competitor starting from zero data on that account is genuinely worse at the job on day one.

This is also the reason the retrofit doesn't work. A legacy help desk's data model is a thread of human messages with a status on it. You can put the best model in the world on top of that and it still doesn't know what the customer pays you.

Where we actually spend

Rough split of engineering time over the last year: most of it on data and context, a meaningful chunk on outcomes and the billing logic underneath them, and comparatively little on the model layer beyond evals and swapping providers when a better one shows up.

That felt wrong for the first few months. The model layer is where the fun is. It's also where you burn a year building something a price cut deletes.

The one thing I'd flag as unresolved: the data layer being the moat is also the data layer being the reason onboarding is hard. Every integration we ship is a week we didn't spend on the product, and the value doesn't show up until a customer has been running for a while. That's a bet on retention that we haven't been alive long enough to fully prove.

Ask me in 2 years.