AI Startup Defensibility: Building a Moat When Everyone Has the Same Models

TL;DR: When every competitor can call the same frontier models, defensibility stops coming from capability and starts coming from what survives contact with production — reliability at scale, workflow depth, and the ability to win a head-to-head evaluation. Based on 200+ founder interviews on the PMF Show, the moats that hold are proven in enterprise POCs, not claimed in pitch decks: founders describe winning bake-offs in six weeks, finding what incumbent tools missed in a day and a half, and building architectures that add compute rather than prompt length as complexity rises. Test your moat by asking what a well-funded competitor would still have to learn after copying your product.

After interviewing 200+ founders on the PMF Show, the honest position on AI defensibility is that almost none of it comes from the model. Everyone got the same capability on the same day. What separates the companies with real moats is unglamorous: they operate where being wrong is expensive, they've solved the last mile of reliability that demos never expose, and they attach to budgets that already exist. This article covers where the founders on the show located their defensibility, and how each of them proved it in front of a customer who was actively comparing them to alternatives.

Why doesn't a better model give you a moat?

Because a demo is not a product, and the gap between them is where all the defensibility lives. Cos Nicolaescu, co-founder of Accrual and formerly CTO at Brex, states the problem more bluntly than most:

"it's very easy to demo stuff in AI. I can build a demo in the next few hours on almost anything and it will impress people. But to actually build a product that can do it at scale and reliability necessary for production and accuracy. Especially in such a regulated industry, is exceptionally hard" — Cos Nicolaescu, Accrual

He was explicitly uncertain at the start whether a moat was even available in his category:

"we had a lot of ideas. And a lot of hypotheses of what we can build, but we had no idea how much of it is real. What technology can actually do in this space and how deep you can go, and how much moat you can actually build as a business versus just swapping some low hanging fruit, and then being done." — Cos Nicolaescu, Accrual

That last phrase — "swapping some low hanging fruit, and then being done" — is the fate of most AI point solutions. Nicolaescu describes what he saw in accounting before starting:

"most solutions that I saw in the accounting space were very point solutions. Where you're taking some type of documents and extracting them, or taking a client portal and showing it to your customers or whatnot. So very, very niche things. Which don't really challenge product market fit. You're not creating a category, you're not doing something unique, you're just hopefully doing something incrementally better." — Cos Nicolaescu, Accrual

Accrual's answer was platform depth rather than a better extraction — building components that all have to click together across a workflow. The proof point was running very complex returns for firms like Armanino and Creative Planning through the entire system, roughly a year in.

Key stat: Accrual's validation was running some of the most complex individual tax returns in the United States end-to-end, about a year after founding.

What does a real technical moat look like in practice?

It looks like an architecture decision that a competitor can't reach by writing a longer prompt. Rafael Broshi of Notch gave the most concrete version on the show:

"So I think we build the product from an architectural standpoint a lot different, where when complexity increases it's not that we increase the prompt size. We increase the number of components of AI, components of LLMs that we use. So essentially when complexity increases, we increase compute, and we built things very, very differently in order to adhere to very accurate and very high standards in, production and complex environments." — Rafael Broshi, Notch

His own summary: "That's the main difference, very technical in that regard, but I think that's what won us the POC."

The origin of that design is what makes it hard to copy. Notch spent five years inside insurance as a managing general agent, selling policies and building software to service its own policyholders. Accuracy wasn't a product requirement, it was a liability exposure. Competitors starting from a blank repository can replicate the interface; they can't replicate five years of learning which failure modes actually cost money.

Note the shape of this moat: it's not proprietary data and it's not a proprietary model. It's an architecture chosen under a constraint most competitors have never operated under. That's a category of defensibility that founders systematically under-claim, because it doesn't sound like a moat until you watch it win a bake-off.

How do you prove defensibility to a customer who's comparing you to everyone?

You win the evaluation, fast, against better-resourced competitors. Broshi's product-market-fit moment was exactly that:

"we worked our asses off. It was a team of like six, seven people on that POC. We slept two nights at the office to get that second version up and running. But once the second version hit, suddenly the entire conversation kind of changed from us being the underdog and giving us a chance just because they wanted another vendor in the POC" — Rafael Broshi, Notch

The signal he extracted from it generalizes better than the war story:

"if we get to an enterprise kind of POC and we figure out a way to be a front runner in the race with less than a week of preparation. That means that we have a good product that already fits those kind of clients." — Rafael Broshi, Notch

He also draws a distinction most founders miss — between having a product that fits and having a team fast enough to build whatever the POC asks for. The second one feels like winning and isn't a moat at all.

Damien Lewke of Nebulock produced the same proof from the other direction. Nebulock is a security product whose entire premise is finding what other tools miss:

"it really was about delivering value out of the box. So we're a security solution and our whole focus is to find what other existing tools have missed. And what happened for us was basically in, I think it was like a day and a half. We caught something that no other tool had found" — Damien Lewke, Nebulock

The organizational consequence was immediate and expensive for the buyer:

"this particular finding, again in a Fortune 500 with many layers of management. Was escalated all the way up to the chief information security officer, so the C-level person who's in charge of all security and it ended up revealing a cultural divide within the company." — Damien Lewke, Nebulock

"what they had done was earmarked budget without any previous negotiation, right? And it was kind of this like we proved it, they made the budget and became our internal champion immediately, and helped drive this extremely fast close." — Damien Lewke, Nebulock

Key stat: Nebulock closed a Fortune 500 deal in six weeks from POC start, as a seed-stage company with about a dozen employees, after finding in a day and a half what incumbent tools had missed.

That's what a defensible product looks like from the buyer's side. Not a claim about architecture — a result no other vendor produced.

Is attaching to an existing budget a moat?

It's not a moat by itself, but it removes the risk that kills most AI startups: spending your defensibility on market education. Dan Mishin of Manifest is precise about the difference:

"There is a difference between creating software to solve a problem that most people don't know exists or better executing and better solving a pain point that is already there. There is already a market, there is already a budget, there is already spend. People already use those services" — Dan Mishin, Manifest

The consequence for his company:

"when you sort of focus on building businesses around existing pain points and replacing existing players. Then the product market fit question becomes a little bit less acute." — Dan Mishin, Manifest

"The PMF was never a question. The bigger question was, can we get supply? Can we get demand at a price that makes sense? Does customer acquisition cost make sense?" — Dan Mishin, Manifest

Manifest's underlying pain is severe enough to be structural. As Mishin describes it, an attorney who starts their own practice will "spend sixty percent of your time doing non billable work". And:

"a person goes to law school, accumulates $300,000 of student loans, and then they end up doing work that doesn't require a law license. Just to sort of become a glorified salesperson." — Dan Mishin, Manifest

"the pain points that lawyers experience are very acute, and the PMF was so strong because the pain point itself was so strong." — Dan Mishin, Manifest

George Kurdin of Monk found the same structure in accounts receivable, and describes what he heard in customer interviews:

"we use X, and it took a year to implement X, and we failed to implement. And it was so disastrous that my team, my entire team, had to take a vacation after implementation." — George Kurdin, Monk

His framing of why that's a good place to build:

"the thing that we do. Which is accounts receivable, we manage the revenue side of the business. Is it's a hard fact that the world accepts that exists, that is broken. Everyone already has some sort of solution, whether that's spreadsheets or another piece of SaaS. We're not inventing that new thing, it's just that we're making the existing thing better." — George Kurdin, Monk

Kurdin's point is that the frustration itself is the asset. As Pablo Srugo framed it on that episode, what Monk picked on was "the frustration of the problem. The status quo that you picked on than the eyes lighting up for your solution necessarily."

Key stat: $300K in law school debt against 60% of time spent on non-billable work — the structural pain Manifest attached to.

What does defensibility look like once you're winning?

It moves. Ali Khokhar of Amigo AI describes a first deal that was itself the proof:

"One of the biggest deals we ever signed, which was our very first deal. Which was a multi six figure contract, got signed in sixteen days during Christmas and New Year's, right? When the world is asleep, when the world shuts down, generally speaking. They came inbound" — Ali Khokhar, Amigo AI

"it very clearly indicated that a fairly larger company, relative to us at the time. Cared so deeply and had such a big hair on fire problem. That their execs were wanting to work through Christmas, through New Year's, in a very short period of time" — Ali Khokhar, Amigo AI

Key stat: Amigo AI's first contract was multi-six-figure, inbound, and signed in sixteen days over the Christmas and New Year period.

But the moat that gets you the first ten customers is not the one that protects customer two hundred. Ben Rudolph of Peregrine identifies where it relocated for them:

"I specifically remember the next bottleneck for Peregrine was that deployment motion that you talked about, like, how did you scale that? When we started getting, you know, not like single digit customers, but dozens and dozens? And then it was like, oh man, how does this even work at scale?" — Ben Rudolph, Peregrine

Deployment capacity is an unfashionable moat and a durable one. A competitor can match your model and your interface and still be unable to stand up dozens of enterprise integrations per quarter. In AI specifically, where the last mile is data integration and change management, the operational machine frequently outlasts the technical differentiator.

How should you spend your time while looking for the moat?

Buying information, not distance. Astro Teller, who runs X, Alphabet's moonshot factory, gave the best mental model on the show for early-stage effort allocation:

"if we were lost in a rowboat. Somehow people get in this mindset of how vigorously I row is going to save us. You know what? If we're lost in a rowboat, I'm going to spend ninety percent of my time with the sextant and ten percent of my time rowing." — Astro Teller, Moonshot Factory

The metric that follows:

"we're buying options on the future and so information gain, the learning per dollar, is what we're actually trying to maximize" — Astro Teller, Moonshot Factory

Teller acknowledges this is hard to internalize "because they have learned that progress is the ultimate metric instead of learning being the ultimate metric." For a founder searching for defensibility, that's the whole point: shipping faster in a category where you have no moat is rowing vigorously in an unknown direction. The founders above all ran the sextant first — Nicolaescu testing whether depth was even available in accounting, Broshi learning failure modes as a licensed insurer, Lewke validating that incumbent tools missed things.

Key Takeaways: Where AI Defensibility Actually Comes From

1. A demo proves nothing. Cos Nicolaescu can build an impressive AI demo in hours; production reliability and accuracy in a regulated industry is the hard part, and that gap is the moat. 2. Point solutions don't create categories. Extracting from documents is "incrementally better," not defensible. Depth across an entire workflow is. 3. Architecture chosen under real constraint is hard to copy. Notch adds compute and LLM components as complexity rises rather than lengthening prompts — a design born from carrying its own liability. 4. Win the bake-off with a week of prep. Broshi's test: if you can lead an enterprise POC on short notice, the product genuinely fits. 5. Produce a result no incumbent did. Nebulock found in a day and a half what other tools missed, and closed a Fortune 500 in six weeks with a dozen employees. 6. Attach to existing budgets. Dan Mishin's distinction between inventing a market and replacing incumbents is why his PMF question was never in doubt. 7. Broken status quo is an asset. George Kurdin built on frustration with existing tools, not excitement about a new one. 8. The moat relocates as you scale. Peregrine's binding constraint became deployment capacity at dozens of customers — an operational moat, not a technical one. 9. Maximize learning per dollar. Astro Teller's sextant-versus-rowing split is the correct effort allocation while the moat is still a hypothesis.

FAQ: Common Questions About AI Startup Defensibility

Q: What creates a defensibility moat for an AI startup?

A: Not model access — everyone has that. The durable sources on the show are production reliability in high-stakes domains, workflow depth across an entire process, architectures shaped by real liability, attachment to budgets that already exist, and operational capacity like deployment at scale.

Q: Is proprietary data enough of a moat?

A: Rarely on its own. Cos Nicolaescu's account of Accrual is about relational context and workflow depth — knowing how documents connect and handling nuanced cases — rather than volume of data. Data without that structure still leaves you doing something incrementally better.

Q: How do I know if my moat is real?

A: Put it in front of a customer who is actively evaluating alternatives. Rafael Broshi's test is whether you can front-run an enterprise POC with under a week of preparation. Damien Lewke's is whether you produce a finding no existing tool produced.

Q: Should I build in a regulated industry for defensibility?

A: It's one of the strongest structural choices, because accuracy requirements and liability exclude thin competitors. Both Accrual (accounting) and Notch (insurance) locate much of their defensibility there. It's also slower and harder, so it needs to match what you're actually good at.

Q: Does the moat change as the company grows?

A: Yes. Peregrine's constraint shifted from product to deployment motion once they went from single-digit customers to dozens. Expect your defensibility to migrate from technical to operational as you scale.

Sources: Listen to the Full Founder Stories

• Cos Nicolaescu, Accrual — on why AI demos are trivial and production accuracy in regulated industries is not, and on running the most complex US tax returns end-to-end.
• Rafael Broshi, Notch — on adding compute rather than prompt length as complexity rises, and winning an enterprise POC as the underdog.
• Damien Lewke, Nebulock — on finding in a day and a half what no other tool had, and closing a Fortune 500 in six weeks with a dozen employees.
• Dan Mishin, Manifest — on replacing existing spend rather than inventing a market, and the $300K-debt pain point behind Manifest.
• George Kurdin, Monk — on building where the status quo is accepted as broken, and what failed implementations sound like in customer interviews.
• Ali Khokhar, Amigo AI — on a multi-six-figure inbound contract signed in sixteen days over the holidays.
• Ben Rudolph, Peregrine — on the moat relocating to deployment capacity once customers hit the dozens.
• Astro Teller, Moonshot Factory — on spending 90% of your time with the sextant and maximizing learning per dollar.

Last updated: August 2026