The software on your laptop probably works fine. The company that made it would prefer you didn’t notice.
Planned obsolescence in hardware gets most of the attention, and rightly so. But the more consequential version operates at the software level, where the expiration dates are invisible, the incentives are layered, and the practice is widespread enough to constitute an industry norm. Here is how the mechanism actually works.
1. Subscription Revenue Requires Perpetual Dissatisfaction
The shift from perpetual licensing to subscription software is the cleanest example of deliberate obsolescence in modern tech. When Microsoft sold you Office 2007 for a one-time fee, the company had a direct incentive to make it excellent enough to justify the purchase. Once Microsoft moved to Microsoft 365 subscriptions, the incentive structure inverted. Now the company needs you to feel, every single renewal period, that the product is improving enough to justify the ongoing charge.
That requires keeping older versions functional enough to avoid outrage but degraded enough to motivate upgrades. It also means the software itself must never feel finished. Features get added not because users need them but because the changelog has to justify the bill. Adobe’s Creative Cloud followed the same playbook. The software didn’t get dramatically better after the subscription switch; the pricing model changed, and the product roadmap followed.
2. API Deprecation Is Forced Migration by Another Name
Enterprise software lives and dies on integrations. When a platform deprecates an API, every application built on that API has a choice: migrate to the new endpoint or break. This is rarely about technical necessity. It is about moving customers onto newer (and usually more expensive) tiers before they get comfortable enough on the old ones to stop paying attention.
Google has deprecated major APIs across Maps, Gmail, and Google Analytics with enough regularity that developers now factor forced migration cycles into project timelines as a cost of doing business. The deprecation schedule isn’t designed to improve the product. It’s designed to prevent the product from feeling like infrastructure, which is the one category of software people stop paying to update.
3. Security Support Windows Create Artificial Mortality
Microsoft’s announcement that Windows 10 support ends in October 2025 is the clearest current example of software expiration dates set by the vendor rather than the technology. As we’ve covered before, the hardware requirements for Windows 11 exclude machines that run Windows 10 perfectly well. The software doesn’t fail. The support contract expires, which is a different thing entirely.
Security patch windows are legitimate in principle. Software does accumulate vulnerabilities, and supporting every version forever is genuinely costly. But the window length is a business decision, not an engineering one. Five to seven years is the standard cycle for consumer operating systems, and it maps neatly onto consumer credit cycles and corporate hardware refresh budgets, not onto the actual technical lifespan of the underlying code.
4. Feature Creep Is the Delivery Mechanism for Bloat
Software that accumulates features over time eventually becomes too heavy for the hardware it originally ran on. This isn’t accidental. Adding features is how product teams justify headcount, hit roadmap milestones, and signal growth to investors. The side effect is that the software’s resource requirements grow steadily while the hardware it runs on stays fixed.
Chrome is the most-cited example. Earlier versions ran comfortably on machines with 2GB of RAM. Current Chrome regularly consumes more than that on its own. Electron-based applications like Slack and VS Code carry an entire browser runtime as overhead. The engineering teams know this. The product incentives override the performance concerns almost every time, because shipping features is measurable and preventing bloat is not. The result is software that effectively expires not because it stops working but because it stops working well.
5. The Ecosystem Lock-In Requires Regular Resets
File format changes, authentication overhauls, and platform migrations serve one underappreciated function: they reset the switching cost clock. A company that has used the same project management tool for ten years has a decade of institutional knowledge and workflow embedded in that tool. That’s lock-in, and it’s valuable to the vendor. But it also means the customer has no particular reason to upgrade.
Major version resets solve this. When a vendor moves to a new file format or rebuilds the product on a new architecture, they force customers to re-evaluate whether they want to migrate with the vendor or switch to a competitor. Most choose to migrate. The exercise reminds customers they’re dependent, which is precisely the psychological state that makes renewal rates high. It also gives the vendor an opportunity to renegotiate contracts during the migration window, when switching costs are temporarily visible and therefore more intimidating.
6. Developer Tooling Enforces Upgrade Cycles on Entire Ecosystems
This is the least visible mechanism and arguably the most powerful. When Node.js drops support for an older runtime, or when a major npm dependency stops supporting older versions, applications built on those tools face upgrade cycles whether they want them or not. The application itself might be stable and well-maintained. The ground under it shifts anyway.
This creates a compounding effect. A company running a stable application from four years ago may find that three of its core dependencies have since deprecated the versions it uses. Upgrading each dependency requires testing, which requires engineering time, which has a cost. That cost is routinely used to justify rebuilding the application on a newer stack entirely, which restarts the cycle. The companies selling the underlying platforms benefit from this churn without ever explicitly engineering it. The market structure does the work for them.
None of this is secret. Engineers know it, product managers know it, and CFOs definitely know it. The interesting question isn’t whether deliberate obsolescence exists but whether it delivers enough genuine value alongside the extraction to be worth tolerating. Sometimes it does. Security patches are real. Performance improvements matter. The answer, for most enterprise software, is that the cycle is somewhat shorter than it needs to be and the coincidence with renewal windows is not a coincidence at all.
