1
1 Comment

Vibe-coding is quietly killing simple SaaS products. The thing that's actually defensible isn't a feature — it's the boring layer

There's a pattern in a lot of "growth has plateaued" stories lately, and I think the two usual culprits — AI Overviews killing SEO, and users vibe-coding their own tools — are actually the same root cause: cloneability.

AI Overviews hurt most when your product is easy to summarize. Users rebuild it themselves when it's easy to recreate. Both are the same problem wearing different hats — if the thing you sell can be explained in a sentence or rebuilt in a weekend, AI now does both for free.

Which leads to an uncomfortable question for anyone building right now: if a competent person with Claude can rebuild your core feature in an afternoon,

what exactly are you selling?
Here's the part I've been sitting with. Everyone's racing to build the clever AI feature - the generation, the summarisation, the agent. But the feature is the most cloneable part of the whole product. It's the first thing an LLM can reproduce. The genuinely hard-to-copy stuff turned out to be the boring layer underneath it:

  • Multi-tenant data that doesn't leak between customers
  • Usage-based billing that meters correctly and doesn't double-charge on a retry
  • Permissions that hold up when a customer's whole team logs in
  • The plumbing that has to be correct, not clever

Nobody vibe-codes that in a weekend. Not because it's intellectually hard, but because it's a hundred small correctness problems that only show up in production, with real money attached. The clever feature is a demo. The boring layer is the moat - precisely because it's tedious and unglamorous and everyone underestimates it.

I'll be honest about my bias: I build infrastructure in this space, so of course I'd argue infra is the moat. But I think the logic holds regardless of what I sell - and I'm not sure where the line is, which is why I'm posting.

So, for the people here:

  1. If your core product could be vibe-coded in a weekend, what's actually keeping your customers from doing exactly that?
  2. Is "hard-to-rebuild infrastructure" a real moat, or just a slower-to-clone one?
  3. What's the part of your product you're most confident an AI couldn't recreate - and why?
on June 13, 2026
  1. 1

    Strong agree, and I'd push it one step further: the reason the boring layer is
    defensible is the same reason AI won't build it for you. A model optimizes for
    the prompt in front of it. It can't see your tenancy model, your billing edge
    cases, or what happens when a background job dies halfway through. So it ships
    the visible 80% and silently skips the 20% that's actually hard.

    The parts that are expensive to copy, in my experience rescuing these codebases:

    1. Multi-tenant isolation. Not "add a tenant_id column" — row-level
      enforcement so a query can't leak across tenants even when someone writes a
      sloppy one. AI code almost never does this; it scopes by whatever ID is in the
      request.
    2. Real authz, not just auth. Login is a solved library call. "Does this
      user own this record" is a system-level relationship the model doesn't model.
    3. Durable execution. Background work that survives a crash and resumes
      instead of re-running from zero. One system I worked on cut ~95% of wasted
      compute just by not re-doing completed steps after a restart (Temporal-style
      workflows).
    4. Billing recovery. insufficient_funds is ~44% of failed charges, and you
      recover 45–55% if you retry inside 24h vs under 15% after 8 days. A
      failure-reason-aware dunning loop is a few days of work and often the
      highest-ROI code in the whole app. The default Stripe handler an AI writes just
      hard-deactivates the account.

    A competitor can clone your UI in a weekend. They can't clone two years of you
    getting tenant isolation, decline handling, and crash-safe jobs right. That's the
    moat — it's just not screenshot-able, so nobody brags about it.