Most investors are still asking the wrong question about defensibility. They ask whether a competitor could rebuild the product. In 2026, the more important question is whether the customer could.

The test changed while we were not looking.

Retool surveyed 817 builders this year and found that 35% of enterprises have already replaced at least one SaaS product with something they built internally. Seventy-eight percent plan to build more. They are replacing workflow automation, admin tools, BI, CRM, project management and support software. These are not bad categories. These are categories venture capital has funded for fifteen years. McKinsey independently puts the build-instead-of-buy number at 32%.

The buyer did not suddenly become a software company. The buyer got a coding agent.

So when a founder tells me the moat is feature depth, integrations or UX, I now apply a simple customer test. If your largest customer decided to clone the product next quarter, would their version be materially worse? If the honest answer is no, you do not have a moat. You have a head start.

What can a customer not build for itself?

I keep coming back to four things.

The first is accountability. When an AI agent acts autonomously inside a customer's systems, someone has to be responsible when it gets something wrong. An internal tool gives you nobody outside the company to hold accountable. In high-consequence workflows, the startup is not just selling software. It is selling the transfer of risk.

The second is data the customer cannot create alone. Not its own data sitting inside your product. I mean data that only exists because you sit across many customers, markets or counterparties. Benchmarks. Fraud signals. Pricing intelligence. A customer can reproduce what it teaches you. It cannot reproduce what everyone else teaches you.

The third is owning the record, not just the interface. AI is making interfaces incredibly cheap to build. But systems holding state and history remain painful to remove because removing them means reconciling records and figuring out what breaks downstream.

The fourth is multi-party position. If you sit between parties that do not want to integrate directly, a customer cannot rebuild your product because it cannot rebuild the other side of your network.

Put these together and the objective has changed.

Stop trying to be hard to copy. Start trying to be hard to remove.

Removal is an organizational problem, not a technical one. I care less about whether rebuilding your software takes six months or six days. I care about how many people must approve removing it, what breaks when you leave and who gets blamed when the migration goes wrong.

This changes how I do diligence.

I want to see the MSA. Who is responsible? Is there an indemnity? What is the liability cap? A contract with real teeth tells me the customer is buying more than functionality. It is transferring responsibility.

I ask whether customers have discussed rebuilding the product internally. I ask why churned customers left and how many rebuilt themselves. I ask how many departments use the product. And I ask the simplest question: what happens when your software is wrong?

There is an uncomfortable implication here.

If defensibility increasingly comes from accountability, trust and relationships, then part of the AI moat is human. That sits awkwardly with our current obsession with tiny AI-native companies.

A company may be able to build its product with almost no employees. It cannot necessarily hold the customer relationship, absorb liability and earn the right to act autonomously on a customer's behalf with almost no employees.

There is an accountability floor below which companies cannot shrink.

We are about to find out where it is.

So stop asking whether a competitor can copy the startup.

Ask whether the customer can.

Then ask who is on the hook when the software gets something important wrong.

Increasingly, I think that person is the moat.