Moats for AI Products: What You Have to Own When the Model Is Rented

Q: Is an AI wrapper a real business?

It can be, but the wrapper is not the asset. Calling a model is available to everyone, so the durable part has to be something else: the workflow you own end to end, the data your customers generate inside your product, the integrations and records other systems depend on, the distribution relationship, or the accumulated process knowledge of a specific industry. If a competent engineer could rebuild everything you have in a fortnight, you have a feature and a head start, not a company.

Q: What makes an AI product defensible?

Four things hold up in practice. Workflow depth, where you become the system a team works in rather than a tool they visit. Proprietary data created by usage, especially outcome data nobody else can observe. Switching costs from integrations, history and compliance records. And distribution, meaning a channel or relationship that reaches buyers your competitors cannot reach cheaply. Model choice is not on that list, because you rent it and so does everyone else.

Q: Do data network effects apply to AI startups?

Only under strict conditions. The data has to be generated by usage, be difficult to buy or scrape elsewhere, and produce a measurably better product with each increment. Most application-layer data fails the third test, because a general model improves faster from its own training than your product improves from your customers' documents. Outcome data, meaning what happened after a decision was made, is the exception that still creates advantage.

Q: Why do most enterprise AI pilots fail?

A widely discussed 2025 report from MIT's NANDA initiative found that around 95 percent of enterprise generative AI pilots produced no measurable profit and loss impact. The pattern behind that number is consistent: pilots demonstrate capability rather than replacing a process, no owner is accountable for the metric that should move, and the tool sits beside the workflow instead of inside it. Products that survive pilot stage are the ones that take responsibility for a step and its measurement.

Your competitor has the same model, the same API key and the same weekend you had. Something else has to be yours.

Two founders build the same product in the same month. One is acquired for a real number three years later, the other quietly shuts down after a large incumbent ships the same capability as a checkbox. The difference was never model choice or prompt quality. It was what each of them accumulated while the window was open.

Renting intelligence from a provider is now the default, which means the intelligence is not the asset. Everything you build on top is a distribution and workflow business wearing an AI coat, and it needs to be defensible on those terms.

If a competent engineer could rebuild your product in a fortnight, you do not have a company. You have a head start with an expiry date.

The market is currently generous about this. Buyers are experimenting, budgets exist for pilots, and being early counts for something. That generosity is temporary, and the evidence is already visible: a widely discussed 2025 report from MIT's NANDA initiative found roughly 95 percent of enterprise generative AI pilots delivered no measurable profit and loss impact. Enormous activity, almost no durable revenue. Buyers will not fund that pattern for a third year.

95%of enterprise GenAI pilots with no measurable P&L impact (MIT NANDA, 2025)

7powers in Helmer's framework; only a few are reachable early

2 weeksthe rebuild time that decides whether you have a moat

Four moats you can actually build early

Hamilton Helmer's 7 Powers lists scale economies, network economies, counter-positioning, switching costs, branding, cornered resource and process power. Most of those require size you do not have. Four are reachable from a standing start.

Workflow depth

The strongest early moat is being the place the work happens, not a tool people visit. A summariser is a feature. A system where claims arrive, get assessed, get approved, get paid and get audited is a workflow, and workflows are replaced during reorganisations, not during procurement reviews.

The test is simple. If your product disappeared tonight, would the customer's process stop, or would they open a spreadsheet and continue slightly annoyed? Everything you build should move you toward the first answer, which usually means taking on the boring adjacent steps: approvals, audit trails, exception handling, reporting to whoever asks for it monthly.

Proprietary data with a feedback loop

Not "we have lots of customer documents." That is a liability with a storage bill. The valuable kind is outcome data: what was decided, what happened next, and whether it worked. Nobody can scrape that, buy it, or infer it from a general corpus, because it only exists where the decision and the consequence are observed in the same system.

The condition for it to be a moat is that each increment measurably improves the product. If your accuracy at 100,000 records is indistinguishable from your accuracy at 5,000, you have data, not a data advantage. Test this explicitly rather than assuming it, because the assumption is how three-year roadmaps get built on nothing.

Switching costs

Every integration, historical record, trained user and compliance artefact raises the cost of leaving. Two years of audit history inside your system is a genuine reason a regulated customer stays. So is being the system that feeds three others via API.

Build these deliberately and honestly. Switching costs earned by being embedded in real work are durable. Switching costs manufactured by refusing to export data are hostage-taking, and buyers now write export rights into contracts because they have been burned before.

Distribution you own

Day 4 made the general case. In AI it is sharper, because capability parity arrives fast and the winner is whoever reaches the buyer at the moment of need. An exclusive channel, a partnership with the association every one of your customers belongs to, a certification that puts you on an approved list, an audience you built over four years: these are all things a better-funded competitor cannot replicate by shipping features.

What you are building on

Improves with your customers' usage

Fragile

Improves with usage, easy to copy

A better feedback loop on a commodity task. Real, but a funded competitor can buy their way to parity. Convert it into workflow depth quickly.

Moat

Improves with usage, hard to copy

Outcome data inside a workflow you own, with integrations and history attached. Time works for you here and against everyone else.

Exposed

Static, easy to copy

A prompt, a UI and an API key. Fine as a wedge, fatal as a strategy. The clock starts the day you get traction and someone notices.

Slow

Static, hard to copy

A licence, an exclusive dataset, a regulatory approval. Durable but does not compound. Good floor, poor ceiling, pair it with a loop.

Difficulty of copying: hard on the left, easy on the right

Two questions place any product on this grid: does it get better as customers use it, and how long would a competent team need to replicate it? The bottom-right quadrant describes most of what shipped in the last two years, which is why the shakeout is arriving.

Audit what you have, not what you plan

Tick only what is true today. Plans are not moats.

Interactive · the defensibility audit

If we shut down tonight, our customers' process stops rather than slows. We hold outcome data (what was decided, what happened next) that nobody else can observe. We have measured that the product performs better at today's data volume than it did at a tenth of it. At least two other systems in the customer's stack read from or write to ours. We hold multi-year records a customer would be required to preserve if they left. We have a distribution relationship a competitor cannot buy their way into this year. We own domain knowledge encoded as rules, checks or taxonomies, not just prompts. Swapping our underlying model provider would not change what the customer buys from us.

0 of 8 true today

0 to 1. You are a feature with a landing page. Pick one moat and put the entire next quarter into it. 2 to 3. Early but real. Workflow depth is usually the cheapest next box to tick, and it drags others with it. 4 to 5. Defensible in your niche. Now widen the workflow before you widen the market. 6 or more. Genuinely hard to displace. Your risk has moved from being copied to being outsold.

Eight statements, each either true today or not. The last one matters most: if your customer would notice a model swap, you sold them a model. If they would not, you sold them a system, and systems are what get renewed.

Why pilots die, and what that tells you about moats

The 95 percent figure deserves more than outrage. Look at what separates the surviving 5 percent and you get a specification for defensibility.

Pilots that die demonstrate capability. Somebody shows that the model can draft the letter, and everyone agrees it is impressive. Nothing in the operating model changes, no headcount moves, no metric has an owner, and when budget season arrives there is nothing to point at.

Pilots that convert take responsibility for a step and its number. "We handle tier-one refund requests under 200 dollars, end to end, and here is the weekly report on volume, accuracy and cost per case." That commitment is harder to sell and much harder to displace, because replacing you now means someone has to own that step again.

Which is the practical link between the two halves of this piece: taking ownership of a step is what creates workflow depth, generates outcome data, and builds switching costs. The same decision produces all three moats.

Do this now: the fortnight test, written down

Write one page answering a single question honestly: if a competent two-person team decided to copy us on Monday, what would they have in two weeks, and what would still be missing? Be specific. "Our UI" takes them three days. "Our prompt library" takes them two, because customers will show it to them. "Eighteen months of labelled outcomes across 40,000 cases in one industry" takes them eighteen months. Whatever appears in the second list is your actual moat, and it is the only thing on your roadmap that deserves protected time. If the second list is empty, you have found this quarter's strategy: put something in it.

The three defensibility stories that are not moats

"We are 6 months ahead." A lead is not a moat, it is a resource you spend. The question is what you convert it into before parity arrives. Six months spent on features produces a slightly better product. Six months spent on integrations, outcome data and a channel produces a position.

"We fine-tuned our own model." Sometimes real, often not. Base models improve on a cadence you do not control, and a general model release can erase a fine-tune advantage in a week. Fine-tuning is a moat when the training data is proprietary and continuously replenished by your own customers. Otherwise it is a temporary cost saving.

"We have a great team." True and irrelevant to defensibility. Teams are how you build a moat, not the moat itself. Your competitor also thinks their team is exceptional, and both of you may be right.

How long each advantage survives contact with a funded competitor

Prompt and UI qualityWeeks

Model choice or fine-tuneMonths

Integrations and historyYears

Owning the workflowYears

Distribution nobody else hasLongest

Relative durability, not a promise. The pattern is consistent across software cycles: things that live in your code are copied fastest, things that live in your customers' operations and relationships last longest. Build in the order of that list, not the order of what is fun to build.

Sequencing: wedge first, moat second

None of this argues against starting with a thin product. A narrow, copyable wedge is often the fastest way to earn the right to a workflow. The failure mode is staying there because the wedge is working and the moat work is unglamorous.

A workable sequence: use the wedge to win 20 customers in one segment, use those customers to learn the two steps either side of your step, take on the messier of the two, instrument the outcome so you can prove a number, then use that proof to reach the segment's association, publication or platform. Each stage funds the next, and by the end you own a step, its data, its integrations and a route to everyone else who needs it.

Moat work never feels urgent while the wedge is growing. It starts feeling urgent about four weeks after a better-funded competitor launches something that looks identical to your homepage, which is roughly two years after the work needed to begin.

The takeaway

Rented intelligence is not an asset. Workflow depth, outcome data, switching costs and distribution are.
Test data advantage rather than assuming it: does the product measurably improve at ten times the volume?
Own a step and its number. That single decision builds three moats at once.
Write the fortnight test. Whatever a competitor could not build in two weeks is your real strategy.
Start with a thin wedge, then convert the lead into position before parity arrives.

Frequently asked questions

Is an AI wrapper a real business?

It can be, but the wrapper is not the asset. The durable part is the workflow you own, the data your customers generate, the integrations others depend on, the distribution you hold, or accumulated industry process knowledge. If a competent engineer could rebuild everything in a fortnight, you have a feature and a head start.

What makes an AI product defensible?

Workflow depth, proprietary outcome data, switching costs from integrations and history, and distribution a competitor cannot cheaply buy. Model choice is not on the list, because you rent it and so does everyone else.

Do data network effects apply to AI startups?

Only when the data is generated by usage, is hard to obtain elsewhere, and measurably improves the product with each increment. Most application-layer data fails the third test. Outcome data, meaning what happened after a decision, is the exception that still creates advantage.

Why do most enterprise AI pilots fail?

MIT's NANDA report in 2025 found roughly 95 percent produced no measurable profit and loss impact. Pilots that die demonstrate capability without changing the operating model or owning a metric. Pilots that convert take responsibility for one step and report its number weekly.

Being first is not a strategy. It is a window.

Kill My Startup examines what founders build during the window, and why so many of them build the wrong thing.

Buy on Amazon →

Sources

MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025," on enterprise generative AI pilots and measurable business impact.
Hamilton Helmer, 7 Powers: The Foundations of Business Strategy.
Andreessen Horowitz, "The New Business of AI," on cost structure and defensibility at the application layer.
Standard analysis of switching costs and data network effects in software businesses.