Your Moat Was Never the Code
35% of enterprises have already replaced a SaaS product with software they built themselves. If you can do that to a vendor, someone can do it to you. A re-audit of the Seven Powers for an era where implementation is free — and eight things that still hold.
Somebody on your team looked at a SaaS invoice this month, pointed an agent at the problem, and had a working replacement by the end of the day. It handles the three workflows you actually used. It costs nothing per seat. The subscription is cancelled.
This is not a thought experiment. Retool's 2026 Build vs. Buy report puts it at 35% of enterprises that have already replaced a SaaS product with custom software, and 78% planning to build more internal tools this year. Gartner has task-specific agents shipping in 40% of enterprise apps in 2026, up from under 5% in 2025. The build-versus-buy line moved, and it moved fast.
Now turn it around, because that's the only interesting direction. If you can do that to a vendor, someone can do it to you. And most founders, asked what stops them, produce an answer that stopped being true about eighteen months ago.
Implementation Was a Delay, Not a Moat
Here is the thing nobody wants to say plainly: AI did not destroy your moat. It revealed that you never had one.
Build difficulty was never a moat in any serious theory of competitive advantage. It was a *time delay*. It took two years to build what you built, so for two years nobody else had it, and that felt like structure. It wasn't structure — it was a queue, and you were at the front of it. The delay was doing the work that you assumed your product was doing.
AI collapsed the delay. What's left standing is precisely what was always load-bearing, and most companies never built any of it, because the queue was long enough that they never had to.
The corollary is the sentence I'd put on the wall: the cost of building collapsed; the cost of being trusted did not. Production is no longer the bottleneck. Distribution, trust and liability are.
The Seven Powers, Re-Audited
Hamilton Helmer's Seven Powers is still the right instrument, because it describes mechanisms rather than vibes. AI doesn't repeal it — it changes which powers are cheap to acquire and which resources produce them. Run your business through this honestly.
Notice the pattern. Every power that survives is downstream of something accumulated in the world — operating volume, counterparties, consent, history, reputation. Every power that dies is downstream of something produced at a keyboard.
The Grace Period You Shouldn't Rely On
An honest caveat: "an agent rebuilt it in a day" is true of the demo and false of the product, and the gap is real today. It's also structural rather than random.
AI-generated systems routinely handle credentials inline or in env files — patterns that do not survive a security review. Prototypes get built for one user and one happy path, with no role-based access control. Production needs security, scalability, compliance, integration and ongoing governance. The organisations that pushed proofs of concept into production first are now the ones dealing with governance gaps, uneven data quality and operational debt.
So the day-one clone usually handles the workflows and none of the obligations.
But treat this as a grace period with a shrinking half-life, not a moat. Every one of those gaps is a known engineering problem being actively automated. Building your defence on "their version won't pass a SOC 2 audit" is building on a depreciating asset. Use the time it buys you to build something that doesn't depreciate.
The Moats You Think You Have
Feature count. Not a moat — a larger specification for an agent to process. Most customers use a narrow subset anyway, so the focused replacement never needs parity.
Engineering effort. Not a moat. Effort is an input *you* paid for, not a cost the next entrant has to pay again. AI has no respect for how hard your original implementation was.
A large codebase. Frequently a liability. It can be an invoice attached to yesterday's decisions. If a smaller generated system serves the valuable workflows with fewer dependencies, your accumulated code raises your carrying cost without raising anyone's entry cost.
Integration breadth. Weak when the integrations run over public APIs and repeatable patterns — agents are very good at generating connectors. A catalogue of shallow integrations becomes a maintenance burden faster than it becomes a barrier.
Being first with a UI pattern. Nearly worthless. Visible interaction patterns are the easiest thing in your product to observe, describe and reproduce. The better the pattern, the faster it spreads.
Ask what a competent competitor cannot obtain by reading your product, querying your public interfaces, and spending heavily for six months.
If the answer is a list of features, you have an implementation lead — which is a clock, not a moat.
If the answer is nothing, you have a marketing problem disguised as a strategy.
What To Actually Build
Eight mechanisms that survive cheap software. Each one includes the first concrete move, because strategy that doesn't reduce to a Monday-morning action isn't strategy.
Why Layering Is the Whole Game
Any single mechanism above can be attacked. Data can be licensed or synthesised. Distribution can be outspent. Certifications expire and competitors eventually earn them. Counter-positioning works right up until the incumbent decides the cannibalisation is worth it.
What's hard is the compound. A product that generates proprietary outcome data, which improves the results, which strengthens the reason to stay embedded, which justifies carrying more liability, which earns the certifications that gate the consented data feeds — that's not seven moats. It's one structure with seven load-bearing walls, and an attacker has to breach all of them roughly simultaneously while you keep building.
The same logic I keep arriving at from the engineering side: the model is not the differentiator, and neither is the code. The differentiator is the accumulated thing you feed it and the loop you run around it.
The Skill That Actually Got Scarce
If code is no longer the constraint, then the founder's scarce inputs are the ones that were always harder and are now exposed without cover:
Judgment about what to build. When you could only ship four things a year, the constraint chose for you. Now you can ship forty, and choosing wrong forty times is a faster way to die than shipping four right ones slowly. Taste is now a load-bearing engineering skill.
Domain depth. The valuable specification is the one that encodes what actually happens in a business — the exceptions, the informal rules, the reasons the obvious design is wrong. That knowledge lives in operators, not in training data. An agent will faithfully build the wrong thing at extraordinary speed.
Distribution and trust. Both are accumulated in public over time, and both are the exact things that cannot be generated the night before you need them.
The uncomfortable read for engineers — and I say this as one — is that the part of this job that was hardest to learn is now the part that's cheapest to buy. The part most of us avoided because it wasn't technical is the part that decides who survives.
Your competitor can have your codebase by Friday. Make sure that's the least interesting thing you own.
Related Reading
- The Knowledge Equation — why what you feed the system outlasts the system.
- Money Maker — the ownership side of the same argument.
- SaaSpocalypse — what the repricing looks like from a customer's desk.
- Indie Hacking, Different Game — the economics when build cost collapses.
- The Re-Soloing — one operator, agents, and the collapse of coordination cost.
