The Simple Version
When a big tech company lets a competitor copy its most valuable feature without fighting back, it’s usually because the feature was never the actual product. The product is the ecosystem, the data, or the switching cost built up around it.
Why Fighting Back Is Often the Worse Move
You’ve probably noticed this pattern. Snapchat builds Stories. Instagram copies Stories. Snapchat’s user growth stalls. Nobody gets sued. Nobody sends a cease-and-desist. Everyone moves on.
Or consider how Spotify watched Apple add nearly identical playlist and recommendation features without filing a single intellectual property claim around the core experience. Or how Twitter (now X) watched a dozen apps build threaded conversations and quote-tweeting mechanics that were indistinguishable from its own.
The instinct is to read this as negligence or weakness. It’s usually neither. Most software features cannot be meaningfully patented. The look and feel of a user interface can be protected in limited ways, but courts have historically been skeptical of broad UI patents. Apple famously sued Samsung over icon shapes and rounded corners, spending years and hundreds of millions in legal fees, and the final damages were a fraction of what Apple originally sought. The lesson most product teams took from that saga was: litigation is expensive, slow, and rarely conclusive.
But the legal cost is only part of the calculation.
The Feature Is the Bait, Not the Trap
Here’s what most coverage of these situations misses. A feature is a reason to show up. What keeps you around is everything underneath it.
When you use Spotify, the feature you can describe to a friend is the Discover Weekly playlist. What actually keeps you from leaving is six years of listening history, a library of saved songs, a social graph of friends who share playlists, and the psychological friction of starting over somewhere new. A competitor can copy Discover Weekly’s interface in an afternoon. They cannot copy your history.
This is the architecture that smart product teams build toward. The feature is deliberately visible and imitable because it drives adoption. The lock-in is invisible and nearly impossible to replicate. Letting a competitor copy the visible part costs you almost nothing, because the part that matters cannot be copied.
Google Maps is a clear example. Apple, Microsoft, and a range of startups have all built mapping products with comparable turn-by-turn navigation. Google has never treated this as an existential threat. The reason is that Google Maps is fed by billions of location data points from Android phones, Google Search queries, and Street View vehicles that have been driving roads for nearly two decades. You can copy the map. You cannot copy the data infrastructure behind it, or the decade-plus head start on training the system with real-world corrections.
The Network Effect Makes Copying Irrelevant
There’s a second mechanism that makes fighting back unnecessary, and it’s worth understanding on its own terms.
Some products become more valuable as more people use them. This is a network effect, and it’s one of the most durable competitive advantages in software. When a product benefits from network effects, a copycat with identical features is still a fundamentally worse product, because it has fewer users.
WhatsApp copied SMS. Then every messaging app copied WhatsApp. None of them displaced it in markets where it had already reached saturation, because the value of WhatsApp is not its feature set. It’s that everyone you know is already on it. A technically superior messaging app with zero of your contacts installed is worth nothing to you.
Slack understood this well. Microsoft Teams copied Slack’s interface closely enough that Slack took out a full-page newspaper ad welcoming Microsoft to the market (and pointing out the ways Slack believed it was still better). Slack wasn’t worried about the feature parity. It was worried, correctly, about Microsoft’s ability to bundle Teams into Office 365 and remove the switching decision entirely. That’s a distribution problem, not a features problem. And it’s the kind of competition that no patent lawsuit addresses.
When Companies Fight Back Anyway, and Why
None of this means tech companies never protect their work. They do, selectively, and the pattern of what they choose to protect is revealing.
Companies tend to fight hard over things that are genuinely hard to rebuild: proprietary algorithms, training data, specific patented hardware implementations, and trade secrets baked into the supply chain. They fight less over interface patterns and feature concepts because those are easier to build around and harder to defend legally.
The other case where companies fight back is when a competitor is copying specifically to extract users before lock-in has happened. Early-stage cloning, where a better-funded company sees an unproven startup gaining traction and builds a near-identical product to crowd it out before it scales, is a real and serious threat. This is partly why the best startup ideas often survive early copying: by the time a large company notices a small one, the small one has usually built enough real user relationships to survive the imitation.
What This Means for How You Think About Products
If you work in product, build software, or are just trying to understand why your favorite app keeps getting cloned without consequence, this framework is practically useful.
The question to ask about any product is not “what can competitors copy?” but “what can they not copy?” The answer is almost always one of three things: accumulated data, network density, or distribution control. Features sit on top of those foundations. They attract users. The foundation keeps them.
When you see a company shrug off a clone, look at what the clone cannot reproduce. That’s what the company is actually selling. The feature you can describe is usually just the door.
