Last year, we shipped a new scheduling feature for a veterinary practice management system. One-page appointment creation. Intelligent slot suggestions based on practitioner availability and appointment type. <200ms load time. By every standard we thought mattered, it was better than what existed.
Users who tried it agreed. They said it was faster, cleaner, easier to understand. And then they went back to the old app. They waited 20 seconds for it to load. They clicked through three screens to do what our tool did in one. Because the old app was already open. Because it was familiar. Because their fingers already knew where to click.
We had the better product. We didn’t have the moat.
I keep coming back to this story because it cuts through so much of the noise around software defensibility right now. Everyone’s asking what makes a product defensible in the age of AI. The answer might be simpler — and less comfortable — than the frameworks suggest.
Everyone’s Talking About Moats
There’s a running conversation in the industry about defensibility. Venture firms — and Google’s leaked “We Have No Moat” memo — kicked it off, though most of that was about foundational AI models and whether any single model can maintain a lasting advantage. That’s an interesting question, but it’s not the one I keep running into. The question I face is closer to the ground: what makes a software product defensible when AI has compressed the cost of building one?
The paradox is hard to ignore. AI makes it dramatically easier to build and dramatically harder to defend. A feature that used to take a team six weeks can ship in hours. The barrier to creating something functional has collapsed — which means the barrier to being replicated has collapsed too. The industry response has been a flood of frameworks: data moats, network effects, speed as a moat, regulatory moats, distribution advantages. Each one neatly packaged, each one partially true.
But most of this discourse comes from 30,000 feet — VCs pattern-matching across portfolios, looking for commonalities in what survives. What’s largely missing is the view from inside a product, from teams that build software used by real people in real workflows, where theory meets mess. I’ve spent years building software in exactly that kind of domain — veterinary practice management, time tracking across European countries, enterprise productivity software. Here’s what I’ve learned about what actually holds.
What the Frameworks Get Right (and Miss)
I keep seeing the same four arguments about what creates defensibility. Each captures something real. None tells the full story.
Speed and execution. Real, but insufficient. In regulated domains, moving fast can literally break the law — ship a billing change that violates fiscal rules and you’re not iterating, you’re liable. Speed is a multiplier, not a moat.
Data. Genuinely valuable — and genuinely misunderstood. Proprietary data can be a real advantage; plenty of companies generate datasets no competitor has. But generating data isn’t the same as having a moat. Data you collect and don’t understand defends nothing. The edge isn’t in holding the data — it’s in knowing what it means and building that understanding into the product. Knowing that a “quick” 15-minute vaccination slot for a new puppy actually needs 25, because first-time owners always arrive with a list of questions — that’s not in a database. That’s domain knowledge baked into product logic.
Compliance and regulatory knowledge. Chronically underappreciated. You cannot vibe-code your way to regulatory trust. Every audit passed, every edge case in fiscal compliance handled correctly, every tax authority integration maintained through changing regulations — it compounds into something a competitor cannot shortcut. A rival can clone your feature set in a weekend. What they can’t clone is a multi-year record of never being the reason a tax filing was wrong — and that record only exists in hindsight, only if nothing ever broke. It can’t be bought, only accumulated. That asymmetry is the moat.
Workflow depth. This is where I want to spend the most time. There’s a category of software I think of as a “System of Consequence” — software where, if it fails, the work stops. Billing breaks. Compliance is jeopardized. Appointments disappear. It’s not a nice-to-have tool that makes a task slightly easier. It’s infrastructure. The business runs on it, and the cost of it going wrong isn’t inconvenience — it’s revenue loss, regulatory risk, and operational chaos. Software that reaches this depth of embedding doesn’t compete on features anymore. It competes on the cost of leaving.
Here’s what the frameworks miss when they treat these as separate categories: the strongest defensibility comes from their messy intersection. Being so embedded in the operational reality of a business that replacing you means retraining staff, rebuilding integrations, re-earning compliance certifications, and accepting months of disruption — simultaneously. Not one moat. A tangle of moats, woven together in the boring middle of daily operations. You won’t find it in the feature list. You’ll find it in the things no one thinks about until they try to leave.
The Workflow Is the Moat
This is the part I know from experience, not from frameworks.
Users don’t switch to better products. They switch to products that fit into their existing behavior with zero friction. The scheduling story isn’t an anomaly — it’s the default. In every product I’ve worked on, the pattern repeats: objectively better tools losing to the one that’s already embedded in how people work.
This isn’t laziness. These are busy people. I spent hours behind the front desk just watching them work — three clients through the door at once, the phone ringing, one receptionist holding it together with an anxious owner and a trembling dog in front of her. In that moment there’s no spare bandwidth to learn a new flow. “Better” is an abstraction. What matters is: can I do this without thinking? Does it work the way my hands expect? Every second of hesitation costs them, and you can watch it land — even though they’d never put it into words.
Strategists have a name for part of this: switching costs. The classic version is tangible — contracts, data migration, the work of ripping one system out and wiring another in. That’s real, but it’s the surface. Switching costs assume a rational actor weighing the price of change. Muscle memory isn’t a calculation — it’s the absence of one. The receptionist doesn’t decide not to switch; her hands decide for her. It’s a narrower claim than switching costs, and a deeper one: the lock-in isn’t in the contract or the data, it’s in your users’ fingers.
We shipped features to users who essentially had to use our product — it was their practice management system, not an optional add-on. Many still didn’t adopt the new capabilities, because the old way was muscle memory. Winning a customer away from an incumbent and getting your own captive users to adopt something new look like different problems; they’re two faces of the same force. Across dozens of locations, I saw the same thing play out: training sticks for a week, then people revert. Training isn’t a one-time event. It’s an ongoing fight against the gravitational pull of how things were done yesterday. And every new hire resets the clock.
Once your product is the muscle memory, you have a moat no feature comparison can overcome. A competitor doesn’t just need to build something better. They need to retrain entire staff across every location, while the business keeps running, while phones keep ringing, while clients keep walking in. That’s not a feature gap. That’s an organizational change management project. Most practices won’t even start that conversation unless something is badly broken.
And if you’re the challenger, understand what you’re actually fighting. You’re not fighting the product. You’re fighting habits, comfort, cognitive load, and the deeply rational calculation that learning something new costs more today than the old tool’s inefficiencies. A better product is necessary. It is nowhere near sufficient.
Moats Erode
The same behavioral inertia that protects you can blind you. You stop investing because users aren’t leaving. The product calcifies. Features that were once embedded workflows become legacy constraints. You mistake captivity for loyalty.
A new generation of users arrives — people who never learned the old way and don’t carry the muscle memory that kept them locked in. Or the workflow itself changes. Telehealth reshapes how appointments work. New regulations restructure billing. Your deep embedding is suddenly in the wrong workflow, and the thing that made you hard to leave now makes you hard to adapt.
Moats aren’t built once. They’re tended. The moment you believe you’re secure is the moment erosion accelerates. Markets shift and challengers arrive no matter what you do. Complacency is the only force that reliably kills an incumbent from the inside.
Stop Building Features. Become the Workflow.
I think about that scheduling feature often. The better product. The 200ms load time. Users going back to the 20-second app with three screens and a workflow from 2015. We were building features. They had built the workflow.
Here’s a test worth running: if a competitor rebuilt your entire feature set tomorrow — and with AI, they can — would users still stay? If the answer depends on your feature list, you’re exposed. If the answer depends on the fact that your product is woven into how people actually work, you have something.
The moat is in the boring middle. Training staff until your product is muscle memory. Handling the compliance edge case that shows up once a quarter. Being the tool that’s already open when the phone rings. None of this is glamorous. None of it makes a good demo. All of it compounds.
Building software is easier than ever. But becoming the workflow — the thing people do without thinking, the system they don’t even notice until it’s gone — that’s still hard. And that’s the point.