Picture this: you’re fifteen minutes from a client presentation, and your design software decides right now is the perfect moment to download a 2.3GB update. You didn’t ask for it. You don’t know what it’s fixing. But if you skip it, something somewhere will probably break. This isn’t a bug. It isn’t poor planning. It is, with almost uncomfortable precision, exactly what the product team intended.
This is worth sitting with, because once you see the mechanics underneath it, you’ll never look at a software update notification the same way again. And it connects directly to a broader pattern of deliberate design choices tech companies use to slow down your experience over time.
The Subscription Trap Hidden Inside Every Update
For most of software history, the business model was simple: build a thing, sell the thing, move on. Microsoft sold you Office 2003 for $400 and that was largely that. The relationship was transactional and finite.
Then something shifted. Somewhere around the mid-2000s, executives started doing the math on what recurring revenue actually meant for company valuations versus one-time purchases. The answer was staggering. A customer paying $15 a month is worth dramatically more to a public company’s balance sheet than a customer who paid $150 once three years ago, even though the actual cash is identical. Wall Street prices recurring revenue at a premium multiple. One-time revenue gets priced like a commodity.
So the industry built a product philosophy around the subscription model, and constant updates became the primary justification for why you keep paying. If the software never changed, the “why am I still subscribing?” question gets very uncomfortable very fast.
Dependency Engineering Is a Real Discipline
Here’s where it gets genuinely interesting, and a little unsettling.
Software teams don’t just add features to add features. They add features that create integration points, which create dependencies, which make switching costs real and painful. Every time Salesforce adds another module that connects to three other modules that your operations team has spent six months configuring, they’re not just delivering value. They’re building a switching cost moat around your business.
The update cycle accelerates this. Each major update introduces new APIs, deprecates old ones, changes file formats, or shifts where data lives. This isn’t accidental complexity. It’s strategic complexity. Your data starts speaking a dialect only that software understands fluently.
This is also why software licenses frequently cost more than the hardware they run on. The license isn’t for the software. It’s a membership fee for staying in the ecosystem, remaining compatible, and keeping the integration web intact.
The Security Theater Problem
Now, some updates genuinely matter. Zero-day vulnerabilities are real. Security patches protect real systems from real attacks. I’m not saying every update is manufactured urgency.
But watch how companies communicate security updates versus feature updates. They’re almost always bundled together. A critical security patch arrives in the same package as a redesigned toolbar nobody asked for and three new AI features that feed your usage data back to the mothership. The security urgency gets applied to the entire bundle, so declining the update feels reckless even when 80% of it has nothing to do with security.
This is a genuine rhetorical move. The legitimate urgency of one component provides cover for the monetization agenda of everything else in the package.
Planned Obsolescence in Software Form
There’s a well-documented hardware version of this story, where tech companies deliberately slow down your old phone when a new one launches. Software follows the same logic, just with less physical evidence.
Major software platforms regularly announce end-of-life dates for older versions. After a certain point, you stop receiving security patches unless you upgrade. This isn’t purely technical necessity. It’s an enforcement mechanism. The old version still works. The code doesn’t rot. But the company withdraws support, which creates real risk for businesses, which forces upgrades, which often require new licenses, new training, and sometimes new hardware to run the heavier new software.
The cycle is elegant from a revenue perspective. The customer never gets to a stable point where the software is simply good enough. Good enough is the enemy of the subscription model.
What This Actually Means If You’re Building Something
If you’re on the building side of this equation, a few things are worth internalizing.
First, the update-as-engagement model only works if your updates actually deliver something users value. Teams that use customer complaints as a product roadmap build updates that feel necessary because they address real friction. Teams that ship updates to justify subscriptions end up shipping bloat, and users notice the difference even when they can’t articulate it.
Second, the complexity moat strategy has real limits. The more painful you make it to leave, the more resentful your customers become. That resentment doesn’t always show up in churn numbers immediately, but it shows up in NPS scores, in word-of-mouth, and eventually in a wave of migration the moment a credible alternative appears. Enterprise software graveyards are full of products that confused “high switching costs” with “customer loyalty.”
Third, there’s a version of this model that’s genuinely honest and genuinely works. If your software is actually improving at a pace that justifies a subscription, you don’t need manufactured urgency. The updates sell themselves. The companies that figured this out early built real compounding advantages over the ones that relied on lock-in alone.
The next time your software tells you an update is available, take thirty seconds to read what’s actually in it. Ask yourself who that update is serving. Sometimes the answer is genuinely you. Often enough, the answer is a quarterly revenue target in a conference room you’ll never see.
That’s not cynicism. That’s just understanding the game you’re already playing.
