No Moat in Software

The Poke lesson

On Christmas Day 2012, Snapchat sat at the top of the App Store and Poke, Facebook's near-perfect clone of it, had failed.¹ Evan Spiegel had expected catastrophe: across 2012 and 2013 Facebook built the clone and put a download button at the top of every Facebook app for tens of millions of users. He called the outcome "the greatest Christmas present we ever received," but says the actual lesson was structural, and it is the one he has codified since: "We learned very, very early on that there's no moat in software." Any piece of software can be trivially copied, so software features or products cannot themselves be a durable competitive advantage.

In his telling Poke failed not because of a feature gap but because it could not replicate the thing that made Snapchat valuable, the existing close-friend communication networks. Copying the product is easy; copying the relationships is not. Spiegel draws the distinction between software, which is copyable, and ecosystems, which are not, and describes his direct response: "We're going to have to be really smart about how we build this business and invest in the things that are hard to copy."¹ Over the following years he says Snap shifted investment toward communication network effects, a creator ecosystem built on its lens tools, and hardware, which he frames as the ultimate anti-copy moat because a waveguide and proprietary projector take years and hundreds of millions to replicate. This is the reasoning behind the premium hardware launch playbook Snap is betting its next decade on, and it commits Spiegel to investing in what is hard to reproduce rather than in what demos well.

The AI amplification

Spiegel argues the principle grows more true as software commoditizes. As of 2026 he observes that "it has never been easier, almost instantly, you can copy nearly any piece of software," and concludes that the earlier investment in non-software moats was right and is increasingly correct.¹ Ben Horowitz has extended the same logic to the SaaS lock-ins once considered safe, arguing that migration pain, data lock-in, and interface lock-in are "pretty much gone" as AI coding tools reproduce products quickly, data exports cleanly, and agents rather than humans operate the interface.

The buyer's voice

Ryan Petersen supplies the demand-side version of the pattern, stating that "selling SaaS to tech companies is going to be a tough business because we can build stuff for ourselves."² He describes Flexport already replacing some vendor software in-house and planning to walk its vendor list demanding rate cuts or, in his phrase, "I'll just vibe-replace you," a dynamic developed further in the saas apocalypse pattern. His own exception, he notes, confirms the rule: Slack survives because "nobody wants to build their own Slack," its moat being a communication network effect rather than its code, exactly the surviving category Spiegel names.

What survives

Across these voices the surviving moats are grounded in scarcity or coordination that cannot be reproduced by iterating a model against a target: communication-based network effects, genuine scale economies, and irreproducible domain data. The proprietary data moat and the accumulated edge cases of a dark-matter moat are the invisible-depth versions of the same conclusion, that code commoditizes while data and hard-won operating knowledge compound.

Tensions

The principle is narrower than it can sound. Relative to paper-and-pencil incumbents, software plainly is a moat, the mirror image tracked by software-driven disruption of legacy industries; the claim is that within software competition, code itself has no durable edge. And the founders who reach it from different seats, Spiegel from network effects, Horowitz from lock-ins, Petersen from the buyer's build-or-buy calculus, largely land on a re-pricing of undifferentiated software rather than the end of software moats.