How to Build a Startup Moat in the Age of AI

Everybody wants to be a DJ, nobody wants to dance. What my venture fellowship taught me about products, customers, and defensibility.

Editorial note: expanded from "Hilariously Early," delivered virtually to Mellie Chow's Emerging Technologies class (MASY1-GC-1800) at NYU's School of Professional Studies on September 22, 2026. The investor references and extended exercises below are additions for this essay, not a transcript of the talk.

I recently heard a line that I think is the perfect way to describe this moment in AI and software development: "Everybody wants to be a DJ, nobody wants to dance."

It's how I've been thinking about startups lately. More people can build the thing they've been imagining. They can get a first version working, put it in front of someone, and improve it without raising money just to get started.

That's exciting. But customers don't show up to the launch party just because you figured out how to launch.

When AI lowers the barrier to building a product, a startup's defensibility has to survive other people getting access to the same tools. That might come from trusted customer relationships, a repeatable way to reach buyers, useful knowledge earned through operating, or a product that becomes part of how people get their work done.

The question is whether you have evidence for any of that.

I talked about this with Mellie Chow's Emerging Technologies class at NYU's School of Professional Studies. The talk was called "Hilariously Early," a phrase that took on a different meaning for me during my venture fellowship at Hustle Fund.

Could someone build your product in an afternoon?

During the fellowship, a question kept coming up when we discussed companies: "Couldn't we just build this in an afternoon?"

I'd get excited about a company and its founders, and then have to sit with that question.

An afternoon is an exaggeration for plenty of products. Getting software reliable, secure, and ready for customers still takes work. A convincing demonstration can hide a long list of problems that only appear when real people start depending on it.

But the question exposed something useful. Sometimes what impressed me was simply the existence of the product. Someone had made a thing that worked. That used to tell you more about the effort and resources behind it than it does for many software prototypes today.

A demo proves that something can work under the conditions of the demo. It doesn't establish whether enough people need it, whether they'll keep using it, or whether the company can serve them economically.

So take the afternoon question one step further. Suppose a competitor reproduces the main feature. What would they still need to do before they could replace your business?

They might need to earn the customer's confidence, handle the exceptions, integrate with existing systems, or reach a group of buyers you already understand.

That's where the useful conversation starts.

What makes a startup defensible when AI lowers barriers to entry?

A startup moat is an advantage that helps a business keep winning customers or serving them profitably as competitors catch up. Defensibility describes how difficult it is to erode that advantage.

Being different is a starting point. If another company can copy the difference tomorrow and offer it to the same customers on similar terms, the protection may be thin.

I don't think AI has invented a completely new set of business fundamentals. It has made the relationship between the cost of building and the difficulty of competing more obvious.

The tools that help you launch can help someone else launch. To understand your advantage, you have to look at what happens after both products exist.

Can you reach customers more effectively? Can you solve a problem that requires context a new entrant doesn't have? Does using the product make it more valuable to the customer over time? Are you becoming more dependable as the work gets more complicated?

There also isn't one moat every company needs. A consumer product, an enterprise workflow, and a technically difficult invention face different competitive pressures. Even investors disagree about which advantages deserve the most attention. a16z's consumer AI argument emphasizes momentum and distribution; NFX's defensibility framework distinguishes early advantages from protections that develop later.

The point is to explain how your particular business gets harder to replace.

Is a vibe-coded startup investable?

Using AI to build a product doesn't settle whether the business is investable. It also doesn't remove the need to understand and maintain what you've built.

There are two questions here that often get mixed together. One is whether a team can deliver dependable software. The other is whether the business is a fit for venture investment.

If you've built a working first version with AI, you've made progress. The next questions concern the customer, the market, and your ability to execute: who needs it, why they choose it, what it costs to serve them, and how the business could grow.

At an early stage, some of those answers will be hypotheses. Investors differ in how much uncertainty they're prepared to accept and what evidence they want at each stage. A pre-seed company shouldn't have to pretend it already possesses the protection of an established business.

But it should be able to explain what it expects to learn next.

On the technical side, I would want to know who can diagnose failures, protect customer data, review changes, and keep the service running. AI assistance doesn't make those responsibilities disappear. It can change how the team handles them.

On the business side, I would want to understand the path from a useful first product to something customers repeatedly choose, and why the opportunity fits the kind of capital being raised.

A small profitable product can be a worthwhile business without fitting venture returns. That distinction matters. You don't need to turn every useful thing you build into a fundraising story.

The afternoon test is a starting question for that discussion. It should never become an automatic rule that an easy-to-build product cannot support a valuable company.

What can a competitor not copy in an afternoon?

For the kinds of early software businesses this question brings to mind, there are four places I would look first. These are candidates for an advantage. Each needs evidence.

Customer relationships and earned trust

Trust matters when a buyer has something to lose if the product fails.

A company may be choosing who will handle an important recurring task. It wants to know that the task will get done, that someone will respond when it doesn't, and that the provider understands the consequences.

A competitor can reproduce your claims about reliability. Matching a customer's accumulated experience with you takes more work.

Look for customers willing to renew, recommend you, or entrust you with a more important part of their work. Then ask why. It's possible they genuinely believe you're great. It's equally possible that nobody has ever reviewed the subscription.

A friendly relationship alone doesn't protect a weak product forever. The useful question is what that relationship enables you to do for the customer.

Distribution that repeatedly reaches the right buyers

Distribution becomes an advantage when you have a repeatable way to reach people who need what you sell and can earn their consideration.

That could involve an audience that trusts your judgment, a partner serving the same customers, or a sales approach informed by a deep understanding of the buyer.

A large follower count doesn't establish that those people are potential customers. A successful launch doesn't establish that you can repeat it.

Ask whether the channel produces customers who stay, and what would make it difficult for a competitor to achieve the same result. A channel anyone can buy on the same terms may still be useful without providing much protection.

Distribution is a way into the relationship. The product has to give people a reason to continue it.

Knowledge and data earned through operating

Some of what you learn from serving a difficult customer cannot be learned from outside the business.

You learn where the process breaks, which exceptions matter, and which apparently small problem causes a customer to give up. If that understanding leads to better decisions or a better product, it can become an advantage.

Data needs the same scrutiny. Calling a dataset proprietary says something about access; it doesn't automatically establish value.

You need a legitimate right to use it, a reason it improves the customer's outcome, and an explanation of why a competitor couldn't obtain an adequate substitute. You also need to distinguish information you collect from information you actually learn from.

A folder full of customer records isn't a strategy. A demonstrated improvement in a task customers care about is more meaningful.

A useful place in the customer's workflow

A feature can be quick to imitate while the surrounding work is difficult to replace.

For a hypothetical scheduling product, displaying available times might be straightforward. Handling the customer's permissions, exceptions, integrations, and coordination across a team could require much more understanding.

Those details matter if customers rely on them. They don't become valuable simply because the implementation is complicated.

Burda Principal Investments' software and AI framework examines workflow depth alongside the value a customer can measure. That's a useful connection: integration should help explain why the product is worth keeping.

The strongest version of this is a product customers would actively choose to rebuild their working habits around. Making it inconvenient to cancel is a poor substitute.

Is an AI wrapper a bad business?

A product built with AI and a product built around an AI model are different things.

You could use AI to help write an ordinary business application that doesn't depend on a model when customers use it. Or you could build a service whose central function depends on a model supplied by another company.

The second is often called an AI wrapper. The label tells you something about the product's dependencies. It doesn't answer every question about the business.

If your main value is a generic result customers can obtain elsewhere with similar effort, a model update or a competitor could put pressure on you. If you're delivering a complete outcome inside a particular workflow, the comparison becomes more involved.

Ask what the buyer would have to take on to replace you. They may have to manage setup, data preparation, integrations, exceptions, or support. They may also decide those things are easy enough to handle themselves.

That's a real competitive question. Calling something a wrapper doesn't resolve it, and calling it a platform doesn't resolve it either.

What evidence should a founder show beyond an MVP?

The next step is to connect each claim to something you can observe.

If your claim is…	Look for evidence such as…	Ask what else could explain it
Customers trust us	Renewals, references, expanded use	Are they actively choosing you or simply not reviewing the decision?
We have strong distribution	Repeated acquisition of relevant customers	Does it work beyond one launch, referral source, or promotion?
Our knowledge improves the product	Better outcomes on a defined customer task	Is the improvement from your learning or an improvement available to everyone?
We're part of an important workflow	Recurring use, meaningful integrations, additional teams adopting	Do customers rely on the value or tolerate the friction of leaving?

None of those signals proves a permanent moat. They give you a way to investigate whether your advantage is becoming more substantial.

It's also fine to discover that you don't have much defensibility yet. NFX explicitly makes that early-stage distinction. The useful response is to identify an advantage you could build through serving customers, then test the mechanism behind it.

For example, suppose you believe that understanding a narrow customer group will help you onboard people more successfully. Choose that group, record where onboarding fails, make a specific improvement, and see whether completion or repeat use changes. That is a hypothesis you can learn from.

"We'll have a data moat once we're big" gives you much less to work with.

Why earning customers still takes work

This is the connection to my work at The Discoverability Company. We help early-stage companies with go-to-market. Making something and getting it chosen are connected problems, and making the first easier doesn't eliminate the second.

AI adds another place where customers can research their options. It also gives founders another set of numbers that can look like progress before they tell us much about the business.

A mention in an answer, a visit to a website, and an incremental purchase are different events. If you want to understand the commercial value, you have to keep following the customer. I don't have a dependable account of that entire journey.

The same caution applies to launches. Just because you have people's attention with a launch doesn't mean you've made progress. Just because you've made a demo work doesn't mean you've made progress.

That connects to what I write about in Patterns of Startup Failure: visible progress can become a distraction from a harder question.

The dancing part, the way I mean it, is participating in the market you're trying to serve. Listening when customers misunderstand you. Finding out why they stopped using the product. Doing the work of becoming useful enough that they choose to return.

The customer doesn't owe you a dance. You have to pay attention to the room.

Thank you to Mellie Chow for inviting me to speak virtually to her Emerging Technologies class (MASY1-GC-1800) at NYU's School of Professional Studies on September 22, 2026, and to her students for the questions. More about my talks and classroom discussions.

A founder exercise to test your startup's moat

Set aside twenty minutes. Write down your answers before opening your product backlog.

1. If someone copied our product this afternoon, what would we still have tomorrow?

Name the actual relationships, distribution, knowledge, or customer habits. For each one, explain what a competitor would have to do to reproduce its value.

If your answer is mostly features, keep going. If you don't have an advantage yet, write down the one you think you could build.

2. What evidence do we have that customers value those things?

Separate three categories: what you've observed, what you infer, and what you haven't tested.

Use evidence appropriate to your stage. That might mean customer behavior in a pilot, repeat use, renewals, referrals, or willingness to pay. Record the time period and the size of the group. A few encouraging conversations can be useful without representing an entire market.

Then write down one result that would make you reconsider your claim.

3. What will we do in the next thirty days to strengthen one advantage?

Pick one action, a way to observe the result, and a date to review it.

If you think trust is the advantage, investigate why customers return and improve one recurring source of frustration. If you think distribution is the advantage, test whether one promising source can bring in another group of relevant users who stay.

Choose a test you can actually finish. The result should help you decide what to do next, even if it disappoints you.

The tools have made it easier to get behind the decks. Put some time on the calendar for the dance floor.