Every startup claims a moat. Few survive contact with customers, competitors, and complexity. The ones that do not are not always wrong about their advantage — they are often wrong about its durability.
The difference between a moat and a momentary advantage is scale. A moat gets stronger as the business grows. A momentary advantage gets weaker. The same pressures that growth creates — more customers, more competitors, more complexity — should reinforce a true moat. When they erode it instead, the moat was never real.
Here are the signals that your advantage will not survive scale.
1. Your Differentiator Feels Like Marketing Copy
“We use AI” is not a moat. “Our proprietary data” is not a moat. “Our unique architecture” is not a moat — not if every well-funded competitor can build the same thing.
The uncomfortable truth is that most software companies run on the same stack, the same cloud providers, the same open-source foundations, and the same talent pool. If your differentiator can be described in a tagline, it can be replicated by a competitor with a comparable budget and six months of focused engineering time.
The signal to watch for is when your differentiator works better in pitch decks than in competitive analysis. When you describe your advantage in a sales meeting, prospects nod. When you describe it in a room full of engineers who have built similar systems, they point out the alternatives.
What works better: Distinguish between differentiation and defensibility. Differentiation is being different. Defensibility is being difficult to replicate. If your differentiator does not have a defensible mechanism — something that gets harder to copy the more you use it — it is not a moat. It is marketing copy that happens to be true today.
2. Margins Shrink Faster Than Growth Expands
The theory of scale is that fixed costs get spread across more revenue and margins improve. This happens in manufacturing. In software, it is not guaranteed.
Many software businesses experience the opposite: as they grow, support costs balloon, infrastructure costs rise, and the talent required to maintain the system becomes more expensive. The economies of scale that should appear fail to materialize because the complexity of the system grows faster than the revenue base.
The signal is simple: unit economics should improve with scale. If your cost per customer is flat or rising as you add customers, something structural is wrong. The moat that should have protected your margins is not operating.
What works better: Track your unit economics by cohort, not in aggregate. Early customers may have been cheap to serve because they were simple, forgiving, or well-suited to your product. Later customers may be more expensive because they require more support, more infrastructure, or more customization. If per-cohort margins are declining, your moat is not holding. You are competing on price or effort, not on defensible advantage.
3. Customer Loyalty Feels Transactional
The most dangerous illusion in subscription software is treating renewal rates as a measure of satisfaction. High renewal rates can mean customers love your product. They can also mean customers are too busy to switch.
Renewals driven by inertia are not a moat. They are a delay. The customer who stays because switching is inconvenient will leave the moment a competitor reduces that inconvenience. And the trend across the software industry is that switching friction is decreasing, not increasing.
The signal is how customers describe your product. Do they say “we couldn’t run our business without it” or “it’s fine, we’ve just been using it for a while”? Do they advocate for you internally or defend the budget? If loyalty feels passive rather than active, the moat is already eroding.
What works better: Measure net promoter score by depth of usage, not by account. A customer who uses one feature passively may renew but will never advocate. A customer who depends on your product for core workflows will defend it. The depth of integration into the customer’s operations is the real moat, not the length of the contract term.
4. You Are Building Faster Than You Are Learning
Shipping velocity feels like progress. It is not always progress. It is possible to ship features at an accelerating rate while the fundamental quality of the product — its reliability, its usability, its architectural coherence — degrades.
The signal is when your team is building more but learning less. Each feature ships without clear hypotheses about what it will change. The metrics that should inform the next decision are ambiguous or absent. The product grows in surface area without growing in depth.
Debt accumulates behind the new features. The codebase becomes harder to change. The team spends more time on maintenance and less on innovation. The velocity that felt like a moat in year one becomes a liability in year three.
What works better: Measure learning velocity, not just shipping velocity. How many assumptions did the team test this quarter? How many features produced the outcome they predicted? How many decisions were reversed based on data? A team that learns faster will outmaneuver a team that ships faster, because learning compounds and shipping without learning accumulates debt.
5. You Depend on a Single Platform
This is the most common hidden vulnerability in modern software. The business is built on top of someone else’s platform — a cloud provider, an API, a marketplace, a distribution channel. The platform relationship is symbiotic until it is not.
The signal is when a platform change creates an existential crisis for your product. An API deprecation. A policy change. An algorithmic shift. A pricing restructure. These events are outside your control, and they can eliminate your advantage overnight.
The companies that learned this lesson the hard way are numerous: businesses built on Facebook’s API, on Twitter’s API, on Amazon’s marketplace, on Apple’s App Store policies. Each platform change created winners and losers. The losers were the ones who had built their moat on someone else’s land.
What works better: Build portability into your architecture from the start. Not because you will switch platforms, but because the option to switch is what gives you leverage in the relationship. A business that cannot leave a platform has no negotiating power and no defense if the platform’s priorities diverge from its own. The moat must be yours, not leased from a landlord.
What the Signals Have in Common
These five signals share a common thread: they are all signs that the advantage is external or temporary rather than internal and compounding. A moat that depends on customers being too busy to switch, on competitors not having noticed yet, on a platform that has not changed its policies, or on momentum that has not been tested — these are not moats. They are circumstances.
Circumstances change. Moats endure.
What I’ve Learned
Five things that have shaped how I evaluate whether an advantage will survive scale:
If your differentiator sounds good in a pitch but disappears in a competitor analysis, it is not a moat. Distinguish between being different and being difficult to replicate. One is temporary. The other is structural.
Margins reveal the truth that narratives hide. If unit economics do not improve with scale, the moat is not operating. Something is getting worse as the business grows, and that something is usually an unaddressed structural vulnerability.
Passive customers are not a moat — they are a timer. Inertia-based retention is a delay, not a defense. The customer who stays out of convenience will leave the moment a convenient alternative appears.
Shipping without learning is not velocity — it is waste. A team that accumulates features without accumulating insight is building debt, not advantage. The features will need to be maintained, and the assumptions behind them were never validated.
If you built on someone else’s platform, you built on someone else’s land. Platform dependence is not a moat. It is a lease. And leases can be terminated. Build portability and optionality into your architecture from the start.