Your Moat Was Never the Code
AI can reduce the effort of reproducing some software features. A reassessment of competitive advantage through distribution, trust, operating knowledge and production requirements.
Consider a hypothetical team replacing a narrow SaaS workflow with an internal tool. AI may reduce implementation effort, but hosting, maintenance, security and opportunity costs remain. That scenario raises a useful strategic question without establishing a one-day replacement or zero total cost.
Retool’s 2026 report surveyed 817 builders, including its customers, in late 2025: 35% reported that their teams had replaced at least one purchased tool with a custom build, and 78% expected to build more internal tools. Those are respondent findings, not a census of enterprises. Separately, Gartner forecast that40% of enterprise applications would incorporate task-specific agents by the end of 2026; that was a forecast, not measured adoption.
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.
Implementation difficulty can delay competition and, in some products, contribute to durable advantage. The strategic error is assuming that historical effort alone guarantees a barrier: competitors may have better tools, a narrower scope or a different design.
AI can shorten some implementation cycles. How much it changes a particular advantage depends on the product’s technical difficulty, operating obligations and access to resources.
The useful distinction is between reproducing visible features and earning trust in a production system. Distribution, reliability and liability can remain costly even when part of the implementation becomes cheaper.
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.
The pattern is a shift in emphasis, not a rule that everything produced at a keyboard loses value. Accumulated operating knowledge, scarce technical capabilities, consent, networks and trust can reinforce one another.
The Grace Period You Shouldn't Rely On
A quick prototype and a dependable product have different acceptance criteria. A successful demo does not establish security, reliability, maintainability or fitness for every customer.
Credential handling should be assessed by exposure, access controls, rotation and operational use. An environment file is not inherently a failed security review; committing secrets or granting excessive access is the issue. Production requirements also include appropriate permissions, scale, integration and ongoing governance.
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.
Layering can make the advantage stronger: proprietary outcome data can improve results, useful workflows can deepen adoption, and maintained controls can support trusted relationships. These advantages can reinforce one another, but competitors may bypass some through narrower scope or a different business model.
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.
If a competitor can reproduce your visible features more cheaply, what still makes the product valuable and dependable? Build that answer alongside the code.
