Planned obsolescence sounds like a conspiracy theory until you start looking at how tech companies actually allocate engineering time, price their hardware, and structure their software licenses. Then it starts looking like strategy.

This isn’t about malice. Most engineers building these products would prefer to build things that last. The pressure comes from somewhere else: from incentive structures, capital allocation logic, and the basic economics of selling technology in competitive markets. Here are the real reasons tech companies build things they know won’t last.

1. Depreciation Cycles Are a Revenue Schedule in Disguise

When Apple releases a new iPhone, it isn’t just launching a product. It’s scheduling revenue. The device you buy today is engineered to a price point that assumes a two-to-three year replacement cycle, and a meaningful portion of Apple’s earnings model depends on that cycle holding. This isn’t speculation. Apple has disclosed that iPhone replacement rates are a key variable in its revenue forecasting.

The hardware itself is often capable of lasting longer. The constraint gets introduced at the software layer, where older devices gradually receive slower performance, fewer features, or dropped support. iOS 17 officially dropped support for the iPhone 8, a phone from 2017 that ran perfectly well on iOS 16. The engineering rationale is real but partial. The business rationale completes the picture.

2. Switching Costs Only Work If There’s Something to Switch To

Lock-in is often discussed as something companies achieve through data, integrations, and network effects. That’s true. But there’s a less-discussed mechanism: the deliberate architecture of upgrade paths.

Microsoft’s product suite is a good example. When Microsoft ended support for Windows 10 in 2025, it wasn’t because the operating system had stopped working. It was because the support lifecycle is a product in itself. Businesses that want continued security patches have to purchase Windows 11 licenses, which in turn require hardware upgrades because of TPM 2.0 requirements that most older machines don’t meet. The “end of life” announcement is functionally a sales motion.

Layered diagram showing technology generations as strata, with older layers degrading while users are pushed upward toward newer products
Obsolescence isn't introduced at end of life. It's architected at the beginning of the product cycle.

This is also why enterprise software contracts are designed the way they are. The obsolescence of one version creates the migration event that renews the relationship on the vendor’s terms.

3. The Real Product Is the Data Generated During the Product’s Lifetime

For many consumer tech companies, the hardware or software is a collection mechanism. Your fitness tracker, smart home device, or free mobile app generates behavioral data throughout its usable life. When the product reaches “end of support,” the company isn’t abandoning a failing product. It’s rotating you into a newer collection mechanism that produces more valuable data.

Older devices generate data in older formats, with older sensor capabilities, feeding models trained on obsolete assumptions. The upgrade cycle keeps the data pipeline current. Companies that operate on advertising or data-licensing revenue have a structural incentive to accelerate this cycle regardless of whether the underlying hardware has worn out.

4. R&D Accounting Rewards the Next Thing, Not the Current Thing

Internally, the incentive structures within tech companies almost never reward engineers for maintaining existing products at parity with new ones. Careers are built on shipping. The team that maintains a stable, five-year-old product receives less recognition and fewer resources than the team building its successor, even when the five-year-old product serves more users.

This creates a self-fulfilling cycle. The maintenance team is understaffed, so the product degrades. The degradation justifies the successor. The successor launches, the old product gets formally deprecated, and everyone involved gets credit for the transition rather than blame for the neglect that made it necessary.

5. Compatibility Is Expensive and Nobody Wants to Pay for It

One of the least glamorous facts about software engineering is that backward compatibility is brutally hard to maintain. Supporting a decade’s worth of APIs, file formats, and hardware configurations requires ongoing investment that produces no visible new features. It’s invisible when it works and catastrophic when it doesn’t.

Companies make a rational calculation: maintaining compatibility indefinitely costs more than the revenue from users who won’t upgrade. Those users eventually get cut off. This is defensible engineering economics in many cases. The problem is that it gets packaged as progress rather than cost management. “We’re focusing on the future” is more appealing than “supporting your old setup costs us more than you’re worth,” but the second sentence is usually the accurate one.

6. Obsolescence Manufactures Urgency That Marketing Alone Cannot

Consumer electronics markets are largely saturated. The smartphone most people own today is meaningfully good enough for everything most people do with it. Without artificial urgency, replacement rates would drop and revenue would flatten.

Feature degradation through software updates, security vulnerability announcements timed to new product releases, and the quiet removal of app support for older operating systems are all tools that create urgency without requiring the new product to be dramatically better. The consumer perceives risk (my device isn’t getting security updates, my apps won’t run) and responds by purchasing. The risk is real. The timing of its announcement is not always coincidental.

7. Investors Reward Growth, and Growth Requires Turnover

The deeper structural reason for all of this is the expectation placed on public technology companies by their investors. A company that builds durable products and replaces them every decade cannot sustain the revenue growth curve that equity markets price into technology stocks.

This creates pressure that runs from shareholder expectations through the board into executive compensation and down through product roadmaps. The engineer building the product that will be deprecated in three years is, in a very real sense, responding to a signal that originated with institutional investors who want consistent year-over-year revenue growth. Those investors benefit from other mechanisms too, but the growth expectation is what drives product strategy at the most fundamental level.

None of this means the products are bad or that the companies building them are acting in bad faith. It means obsolescence is load-bearing in the business model, and the next time a company tells you a product is being sunset “to focus on the future,” you have permission to ask whose future, exactly, they mean.