← Teardowns

What "Moat" Really Means for a Software Business

Most software has no moat — just a head start. Here's how to tell real defensibility from a UI that any AI coding tool can clone in a weekend.

The word gets thrown around like it means "we have users"

Every pitch deck has a slide called "Moat" and every one of them is wrong in the same way. Founders list things like "strong brand," "first mover advantage," or "beautiful UX" as if these were fortifications. They're not. A moat, in the original Warren Buffett sense, is a structural reason a competitor cannot take your customers even if they copy your product feature-for-feature. Notice the qualifier: even if they copy it. If your entire defense evaporates the moment someone builds the same thing, you didn't have a moat — you had a lead. Leads shrink. Moats don't.

This distinction matters more now than it did five years ago, because the cost of copying the *product layer* of software has collapsed. An AI coding tool can look at your app, infer your data model, and spit out a working clone of your CRUD screens, your dashboard, your onboarding flow, in an afternoon. If that's all you had, congratulations, you built a demo. The businesses that survive this era are the ones whose value never lived in the UI to begin with.

Cloneability and moat are two different axes — and most founders only measure one

At oneprompt we score software on two independent axes because they answer different questions. Technical cloneability asks: how much effort would it take a competent team with modern AI tooling to rebuild this thing's functionality? Business moat asks: once they rebuilt it, would anyone actually switch to it? A product can be trivially cloneable and still un-disruptable (think: a note-taking app with 10 years of your data and habits baked in). A product can also be technically gnarly and still have zero moat (a scraping tool with clever anti-bot tricks that a competitor routes around in a week).

The dangerous quadrant is high cloneability, low moat — pretty apps that are really just a form, a database, and a Stripe integration wearing a brand. There are thousands of these. They raise money on "traction" that's really just ad spend, and they get eaten alive the moment someone with a faster ship cycle notices the market exists. The goal of evaluating a business isn't to ask "is the code hard to write" — LLMs made that question mostly irrelevant. It's to ask what happens on day two, after the clone exists and works.

Real moats, in order of how often people fake them

Compare that list to what most seed-stage decks put on the moat slide: "proprietary algorithm" (usually a prompt and a for-loop), "strong community" (a Discord with 40 active users), "first mover advantage" (a head start measured in months, not structural years). None of those survive a clone with a marketing budget.

  • Data network effects: the product gets measurably better for every user as more users join — fraud detection models, recommendation engines, marketplaces with liquidity. Copying the code gets you an empty database, not the moat.
  • Switching costs baked into workflow: not "we're sticky" hand-waving, but literal integrations, custom fields, historical records, permissions, and muscle memory that would take a customer real weeks to migrate. Payroll, ERPs, and EHRs live here.
  • Regulated or certified access: HIPAA, SOC 2, PCI, FDA clearances, banking charters, government procurement approval. These aren't features you code, they're years-long processes with lawyers and auditors. A clone starts from zero regardless of how good its code is.
  • Proprietary supply relationships: exclusive data feeds, distribution deals, or hardware partnerships a startup can't get by signing up for an API. This is why a clone of Bloomberg Terminal's UI is worthless without Bloomberg's data contracts.
  • Economies of scale that are actually economic, not vibes: unit costs that only make sense at volume (payment processing float, ad auction data, logistics density). A clone at zero volume literally cannot match your price.

Why AI coding tools make this test brutal and clarifying

Before AI coding assistants, cloning even a mediocre SaaS product took a small team several months — enough time that a founder with real traction could widen the gap. That friction was accidentally propping up a lot of businesses that had no actual moat; they just had a slow-to-copy UI. That friction is mostly gone. A single competent engineer with Claude or Cursor can rebuild the CRUD, the auth, the Stripe billing, the dashboard charts, and a passable onboarding flow for most B2B SaaS products in days, not months.

This is good, actually — it's a forcing function for honesty. If your business can be meaningfully damaged by someone rebuilding your app in a weekend, that was always going to happen eventually; AI just moved up the timeline. The founders who get uncomfortable reading this are usually the ones who've been quietly relying on build-time friction as their entire strategy. The founders who shrug and say "sure, clone the UI, good luck getting our customers' 6 years of invoice history migrated without downtime" are the ones with an actual business.

How to actually test your own moat (or a company you're diligencing)

This is the exact pairing oneprompt scores every site on: a cloneability score (how fast/cheap could this be rebuilt with current AI tooling) and a moat score (would anyone switch if it were). Cheap to clone plus low moat is a red flag for an acquirer or investor, not necessarily for a builder — sometimes a fast, cloneable, low-moat product is exactly the right thing to ship this quarter to learn something. The mistake is confusing that kind of product with a durable business and pricing or fundraising it like one.

  • Ask: if a clone existed today, at price zero, would our best customer switch? If yes, you have a UI, not a moat.
  • Ask: does the product get worse for the clone as our user count grows, independent of features? If there's no data or network compounding, there's no moat, just a market.
  • Ask: how long would our own team need to rebuild this from scratch with today's tools, ignoring the business relationships? If the answer is days, your defensibility better live somewhere other than the codebase.
  • Ask: what regulatory, contractual, or integration barrier would a clone hit that isn't solvable by writing more code? If none, keep digging — you probably don't have one yet.

The uncomfortable takeaway

Most software companies do not have a moat. They have a working product, a marketing channel, and a temporary lack of competitors who've noticed. That's a fine place to start a company — plenty of good businesses are built on execution speed and distribution, not structural defensibility. But call it what it is. If your entire pitch is "nobody's built this exact combination of features yet," you're describing an opportunity, not a moat, and the AI-tooling era has made that gap close faster than it ever has before.

The businesses worth building for the long haul are the ones where, when someone clones the app perfectly, they still can't take your customers. Everything else is a race, and races get won by whoever ships next, which increasingly means whoever prompts best.

Want the same teardown for any site?

Analyze a site →