AI Is Not a Moat

Before you plan anything, answer one question: if a competitor's foundation model gets twice as smart and half as expensive next quarter, does that kill your product or make it better? Most failed AI products never asked it. They shipped a demo, felt the pull of "the model can do this," and skipped straight to building. Then a better model arrived, or a competitor cloned the prompt in a weekend, and the thing that felt like a product turned out to be a wrapper with a shelf life.

This is the second post in the From Demo to Product series. The first was about the 95% of engineering that turns a demo into a product. This one is about the strategy question sitting underneath all of it: defensibility.

The model is electricity, not the factory#

Nobody wins a market because they "use electricity." Every competitor is on the same grid. The moat is what you build powered by it: the factory, the supply chain, the customer relationships that took years to earn.

Foundation-model access is that same utility now. The same API, the same rough capability tier, available to your best-funded competitor and to a solo builder on a Sonnet API key. If your product's value is the model, a thin prompt wrapped in a UI, you have no more defensibility than someone reselling electricity by the kilowatt.

a16z put it in one line in their enterprise-builder playbook: "AI itself is not a moat: it is a way to deliver value to customers." Wrapping a prompt around an API commoditises exactly as fast as the underlying model improves. The durable part has to sit on top.

The four moats that hold up#

Cross-check a16z's enterprise piece against Joe Reis's independent 2026 moat framework and you get nearly the same short list. Four mechanisms survive model commoditisation in enterprise AI:

Proprietary data, structured for the task. Not data you happen to touch, data others cannot get, shaped for your specific job, that compounds with usage. Reis's sharpest line: bad data models do not get saved by a smarter model, because "LLMs will query garbage." As capability commoditises, data scarcity is the moat, not data volume.

Deep workflow integration. The customer-specific plumbing that makes the product work inside a real, messy workflow: legacy systems, internal APIs, the institutional exceptions nobody documented. This is the unglamorous, hard-to-copy work a thin wrapper skips, and it is exactly what makes a solution work in the real world rather than the demo.

System of record. Becoming the source of truth for the critical data in a workflow. Accuracy is a great wedge to get in fast, it sells itself. System-of-record status is what makes the value endure after a competitor matches your accuracy.

A product experience that compounds with usage. Memory, learned preferences, accumulated context. The product gets better for this specific user than a fresh competitor's instance ever could on day one.

The test that ties them together: if a foundation model gets twice as good next quarter, a smarter model should make your data more valuable, your workflow stickier, your record-of-truth more central. If it kills you instead, you were a wrapper.

The complication nobody likes: consumer is different#

I want to be honest about a place the tidy four-item list breaks, because smoothing over it would be the dishonest move.

a16z's own consumer-AI writing argues almost the opposite for consumer apps: traditional moats do not hold when models and infrastructure reshuffle monthly, so the substitute is momentum. Whoever builds first, iterates fastest, and distributes best wins. Paid acquisition and SEO are explicitly called unreliable for lasting retention in that environment.

Momentum is a weaker thing than a moat, and the source knows it. It is self-reinforcing only while you keep running. Stop shipping faster than the market and it evaporates. It is a race you are winning, not a wall you have built.

Read the two pieces as describing different terrain, not disagreeing about the same ground. Enterprise AI can build real, durable moats, because enterprise switching costs and integration depth are slow to erode. Pure consumer AI often cannot yet, and races on shipping velocity instead, hoping one of the four structural moats forms before the music stops. If you are building consumer, treat momentum as a strategy to buy time, not a destination.

Build versus buy: two different decisions#

These get conflated constantly, and they are not the same call.

The first is about the components of your product, and it is your call. Buy or rent the commodity layers: foundation models via API, a vector DB, tracing, auth. Build only the differentiated core: your data pipeline, your evals, your workflow logic, your UX. Training your own foundation model is almost never the differentiator.

The second is whether your customer builds this themselves, and that is their call. The enterprise market has swung hard toward buying. Menlo Ventures' 2025 State of Generative AI report puts a number on it: enterprises purchased 76% of AI use cases in 2025, up from 53% in 2024. A reversal in a single year, corroborated by a16z reporting the same direction. Both flag the same exception: regulated industries keep building internally, because the compliance burden a vendor would have to absorb is not worth it to either side yet.

That buying trend is good news for you, but only conditionally. If your differentiation is genuinely hard to replicate in-house, "just build it internally" stops being your customer's obvious first move. If your product is a thin wrapper their own engineers could clone in a sprint, the shift does not protect you. It just means they buy the clone from whoever ships it first.

The output: a one-paragraph thesis#

If you cannot write this crisply, you are not ready to plan the build. The template:

For [user], [painful, frequent job] currently costs [time, money, errors]. We can be [10x claim] on cost or time because [why now]. The wedge is [narrow first workflow], and the moat is [proprietary data, workflow integration, system of record, or compounding UX], so a 2x-better foundation model makes us better, not obsolete.

A worked version, for a month-end close: "For a 50-person accounting team, reconciling invoice line items against POs and flagging exceptions costs three days of a senior accountant's time. We can be 10x faster because extraction-plus-matching is exactly the fuzzy-input, checkable-output shape LLMs are good at, and no incumbent ingests this client's chart-of-accounts quirks. The wedge is automated line-item matching with human sign-off on exceptions. The moat is becoming the system of record for reconciliation history: every close makes the exception-matching more accurate for this client, which a fresh competitor cannot replicate on day one. A smarter model makes our matching better; it does not replace the accumulated client-specific history."

The traps#

A few ways teams fool themselves here, all of which I have watched happen:

Calling data you merely process a "data moat." A real data moat means the data is shaped for your task and hard to reconstruct, not just present in your database.

Answering the 2x-smarter-model test reflexively. Teams say "it helps us" without checking whether their differentiated layer actually decouples from base-model capability. If a better model makes your prompt engineering obsolete for free, you answered wrong.

Confusing momentum with a moat. Growth-hacking velocity feels like defensibility right up until a faster competitor appears, and then it feels like nothing.

Where this goes next#

Defensibility assumes you have picked a problem worth building on. But a lot of AI ideas fail an even earlier test: they should not have been an LLM problem in the first place. The next post is the fit gate, does your problem even need an LLM, and the one before this, if you skipped it, is why the demo is only 5% of the product.