The simple version
Sometimes a profitable product threatens something more profitable, and the bigger number wins. Other times, the math of keeping it alive is worse than the math of killing it, even if it’s technically in the black.
When profit isn’t the point
In 2012, Google killed Google Reader. It had tens of millions of users and, by most accounts, functioned extremely well. It wasn’t hemorrhaging money. Google shut it down anyway.
That decision confused a lot of people at the time, and it still comes up whenever someone wants to illustrate corporate callousness. But it wasn’t callousness. It was a calculated resource decision dressed up in the language of “focus.”
This happens constantly in the software industry, and it follows a surprisingly consistent logic once you understand the forces involved. Profitable software gets killed for reasons that have nothing to do with whether users like it or whether it makes money.
The opportunity cost problem
The first force is opportunity cost. A product can be profitable in absolute terms and still be a bad investment relative to everything else the company could do with the same engineers, servers, and executive attention.
Imagine a product generating a few million dollars a year with a team of twenty engineers maintaining it. That sounds fine until you consider that those twenty engineers could be working on a product the company believes will generate hundreds of millions. The profitable product isn’t failing. It’s just losing the internal competition for resources.
This is especially brutal in big tech, where the opportunity costs are enormous. A team at Google or Meta isn’t competing against industry averages. They’re competing against the expected returns on whatever else Google or Meta could deploy that team toward. Most products can’t win that race.
The cannibalization trap
The second force is more counterintuitive: a profitable product sometimes has to die because it’s eating the margins of a more profitable one.
This is classic cannibalization, and it’s been happening in software longer than most people realize. When a company has a high-margin enterprise offering and a lower-margin self-serve product solving the same problem, the self-serve product creates pricing pressure. Sales teams get undercut. Enterprise customers ask why they’re paying ten times as much. The profitable cheap product is actively eroding the economics of the profitable expensive one.
The math is ugly but clear. If keeping the smaller product alive costs you even a modest percentage of conversion on your enterprise tier, the smaller product’s profits don’t compensate for what it’s destroying upstream. You kill it not because it’s losing money but because it’s costing you money in a way that doesn’t show up in its own P&L.
This dynamic shows up in how companies price their products from the beginning, and the companies that don’t think about it early tend to engineer themselves into exactly this trap.
The maintenance tax
The third force is the one people underestimate most: the real cost of keeping software alive is not what it takes to run it today. It’s what it takes to run it five years from now while everything around it changes.
Software does not sit still. Security vulnerabilities need patching. Underlying infrastructure gets deprecated. Compliance requirements shift. APIs you depend on disappear. The product that costs X to maintain this year will cost significantly more than X to maintain in three years, and the team that knows it best will have moved on to other things.
This is a slow tax that rarely shows up in any single quarter’s numbers, so it doesn’t trigger alarms until it becomes a crisis. By then, keeping the product alive requires a major reinvestment that makes no business sense given the product’s size. The honest version of “we’re sunsetting this product to focus on our core offering” is often “we let the technical debt accumulate until reviving it would cost more than it’s worth.”
The acqui-hire aftermath
There’s a fourth scenario that’s particularly common and particularly cold: the product wasn’t the point of the acquisition. The people were.
A large company acquires a smaller one primarily because it wants the team or the technology, not the specific product. The product has loyal users and turns a profit. But integrating it into the acquirer’s infrastructure would cost engineering resources the acquirer doesn’t want to spend. The alternative, keeping it running independently as a subsidiary, creates organizational complexity nobody wants. So it gets shut down, the team gets absorbed, the users get an apologetic blog post, and the acquirer moves on.
Users experience this as a betrayal. From inside the acquiring company, it often looks like a straightforward resource allocation decision that most people didn’t think twice about.
What this means for users
If you rely on software for something important, the fact that it’s profitable is not the protection you think it is. The more relevant questions are: Is it the acquiring company’s core business? Does it compete with something more profitable that the same company sells? Is it old enough that the maintenance burden is growing faster than the revenue? Is the team that built it still there?
None of these are guarantees. But they’re much better predictors of a product’s survival than whether it’s making money. Churn data tells you a lot about a product’s real health, but no amount of healthy metrics protects a product from being the wrong shape for its owner’s strategy.
The uncomfortable truth is that software companies are not in the business of maintaining software. They’re in the business of allocating capital toward returns. Those are sometimes the same thing, and sometimes they aren’t. When they diverge, the capital wins every time.
