You open an app and something is broken. A feature that worked yesterday now throws an error. A button is grayed out. A workflow you rely on has been reshuffled into something unfamiliar and slightly worse. Your instinct is to blame incompetence, rushed code, or a bad sprint. But a growing pattern across major tech companies suggests something more calculated is happening. Temporary brokenness, it turns out, is often a feature, not a bug.

This connects to a broader pattern of deliberate technical friction that runs through the industry. As we’ve explored before, tech companies deliberately make their APIs difficult to use and then profit from the confusion, and the same logic applies when brokenness gets baked into the product experience itself.

The Concept of Engineered Friction

Software engineers have a concept called “deliberate degradation,” where a system is intentionally made to perform below its capability for a defined period. This isn’t carelessness. It’s architecture. The reasons range from A/B testing and feature flagging to staged rollouts and behavioral nudging, and each one serves a business objective that has very little to do with your user experience.

Take feature flags, which are essentially on/off switches baked into production code. A company can deploy a feature to 5% of users, observe how those users behave, and then gradually widen the rollout. During that process, the other 95% of users are running software that is, technically, incomplete. They’re using a version of the product that has been intentionally held back. This is standard practice at companies like Google, Meta, and Spotify, all of which run hundreds of simultaneous experiments at any given time.

But staged rollouts are the polite version of deliberate brokenness. The more strategic version involves something closer to manufactured dependency.

Breaking Things to Build Habits

Here’s a counterintuitive finding from behavioral research on product design. When a feature disappears temporarily and then returns, users engage with it more intensely than they would have if it had simply always been there. Intermittent reinforcement, the same psychological mechanism behind slot machines, makes users more attentive to the thing they thought they might lose.

This is not a fringe theory. It’s a documented design pattern. Some product teams refer to it informally as “availability cycling,” where a feature is deliberately degraded or hidden during a period when the company wants to re-establish its perceived value. When it comes back, it feels new again. Engagement metrics spike. The feature gets credit it hadn’t earned through improvement, only through absence.

This is related to why successful apps are designed to be forgotten, and that is exactly how they keep you. The psychology of re-engagement is built on the premise that absence, and mild frustration, primes users to return more forcefully.

The Migration Forcing Function

Another common pattern is deliberate brokenness as a migration tool. Legacy systems are expensive to maintain. Old APIs, old interfaces, and old workflows have to be killed off eventually. But users resist change, especially in enterprise software where workflows are deeply ingrained.

So instead of forcing a hard cutover, product teams sometimes make the old thing progressively worse. Response times slow. Error rates creep up. UI elements get harder to find. The new thing, meanwhile, gets polish and speed. Users migrate not because they were told to but because the old path became unpleasant enough that the new path felt like relief.

This is a version of the same logic behind tech companies deliberately slowing down their fastest features. Speed and smoothness are allocated strategically, not evenly, and the allocation reflects where the company wants attention to go.

Salesforce has used versions of this approach repeatedly across major platform transitions. Adobe’s shift from boxed software to Creative Cloud involved a period where perpetual license versions received progressively fewer updates, making the subscription path feel like the obviously better choice. Neither company announced “we are making the old thing worse.” They didn’t have to.

The Testing Cover Story

One reason this pattern persists is that it has excellent cover. Every broken feature can be attributed to testing. Every degraded experience can be chalked up to a rollout gone sideways. Users don’t have good visibility into whether their broken experience was accidental or intentional, and companies rarely clarify.

This ambiguity is useful. It means the company absorbs the reputational cost of an “accident” while capturing the behavioral benefit of a deliberate design choice. And because software demos always work perfectly because they are not running the same software, the gap between what users see in a product presentation and what they experience in production can be enormous without anyone technically lying.

The asymmetry of information here is significant. Engineers know exactly what state the software is in. Product managers know which cohorts are receiving degraded builds. But the user sees only a spinner and an error message, and usually assumes it’s their connection.

When Brokenness Becomes a Business Model

The most sophisticated version of this pattern is when temporary brokenness is the product. Enterprise software vendors have long understood that a customer embedded in a broken-but-familiar system is often more loyal than a customer in a working-but-unfamiliar one. Switching costs are built not just through data lock-in but through workflow dependency, even when that workflow is frustrating.

This connects directly to how tech companies deliberately cripple their best features as a tiering strategy. A free or lower-tier user experiences a version of the product that is structurally incomplete, and that incompleteness is designed to be felt. The friction is the upsell.

What makes this particularly effective is that users often interpret the friction as a technical limitation rather than a business decision. The brokenness feels like a natural constraint of the technology, not a choice made in a product strategy meeting. That misattribution is the entire point.

The next time something breaks in an app you use daily, it’s worth asking a different question than “why can’t they fix this?” The better question is: who benefits from this being broken right now, and for how long? The answer, more often than feels comfortable, is the company that built it.