
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:
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:
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:
tenant_idcolumn" — row-levelenforcement 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.
user own this record" is a system-level relationship the model doesn't model.
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).
insufficient_fundsis ~44% of failed charges, and yourecover 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.