Obsolete by design - Right to keep things working

Right to Repair is often framed around physical repair: batteries, screens, components, spare parts, tools and manuals.

That is still important.

But I think the bigger issue is now wider than repair. It is about hidden dependencies.

More and more products are sold as physical devices, but their useful life depends on software, cloud services, apps, APIs, servers, authentication platforms, mobile operating systems, network standards and vendor goodwill.

The device may still work perfectly well in hardware terms. The speaker, watch, car, camera, thermostat or hub may still be capable of doing the job it was bought to do.

But if the supporting service disappears, the app is withdrawn, the API is closed, the server is switched off, or the vendor refuses to provide a basic part, the product can become degraded, stranded or effectively useless.

That is not just a repair issue. It is a resilience issue. It is also a sustainability issue.

There are plenty of examples.

Sonos is one of the more visceral ones. The “Recycle Mode” controversy was not just about ending support for legacy devices. It was about working devices being deliberately bricked as part of a trade-up programme. Whatever the commercial rationale, the message to customers was stark: a product that still had physical utility could be made unusable by a vendor-controlled lifecycle decision.

That is a very different proposition from “this product will no longer receive new features”.

Bose is another example from the connected audio space. Many people bought SoundTouch systems as premium, connected speakers. When cloud support and app-based functionality come into question, the concern is not just losing a few nice-to-have features. It is the risk of expensive connected audio equipment being pushed back towards dumb-speaker status because the supporting service layer has moved on.

To Bose’s credit, the more recent direction appears better than simply bricking devices: retaining local control, preserving some core functionality and publishing API documentation are exactly the sort of mitigations manufacturers should be considering. But the fact that this became an issue at all shows the problem. The value of the product was never just the hardware. It was the hardware plus the cloud, app, API and service ecosystem around it.

Nissan is another useful example. Some older connected car services depended on mobile network technologies such as 2G or 3G. When those networks are deprecated or switched off, remote app functionality can disappear even though the car itself remains perfectly usable.

My Garmin MARQ Aviator is a personal example that still irritates me. The issue was not that the watch was obsolete in any meaningful sense. The issue was that the manufacturer would not replace the battery to allow my watch to continue its useful life, instead it will end up being "recycled". (Garmin did offer to a service swap for a significant fee). That feels worse than many of the things Apple is criticised for in this area.

To be fair, manufacturers cannot support every product forever. Technology changes, components disappear, security requirements move on, networks are retired and there is a real cost to maintaining old services.

But there should be a better middle ground.

If a manufacturer decides to withdraw support for a connected product, there should be an obligation to think about continuity. That does not have to mean free support indefinitely. It could mean publishing enough information for competent users, communities or third parties to keep basic functionality alive.

Logitech is an interesting example of the better approach. When support for some older server-dependent products ended, enough information was made available for the community to keep things going. That is not perfect, but it is much better than silently turning a working device into electronic waste.

This is where I think we need a broader concept: Right to Repair Plus.

·      Not just the right to open a device.

·      Not just the right to replace a battery.

·      Not just the right to access spare parts.

But the right to understand, maintain and preserve the dependencies that make the product usable.

For connected products, the bill of materials is no longer just physical. It includes services, apps, cloud platforms, authentication systems, APIs, network dependencies and data flows. If those are essential to the product, they should be treated as part of the product’s lifecycle.

That also makes this an ESG issue, not just a consumer-rights issue.

It is difficult to talk credibly about sustainability while designing products that can become landfill because a cloud service has been retired, an app is withdrawn, an API is closed, or a battery cannot be replaced. Avoidable electronic waste is not an acceptable side effect of a product lifecycle strategy.

At the point of sale, consumers should have clearer answers to questions such as:

·      How long will the app be supported?

·      What happens if the cloud service is retired?

·      Does the product have a local or offline mode?

·      Are replacement batteries or key parts available?

·      Can data be exported?

·      Will APIs or documentation be released at end of life?

·      What functionality depends on the vendor staying interested?

This matters for sustainability, consumer trust and basic fairness.

A premium product should not become waste simply because a vendor has moved on. Nor should basic functionality depend unnecessarily on a remote service where local control would have been perfectly possible.

This is not anti-innovation. It is the opposite.

Good product design should include graceful degradation, transparent dependencies and credible end-of-life planning.

If a product is sold as a long-lived physical object, the manufacturer should not be able to treat it like a disposable subscription endpoint.

Right to Repair was the first step.

The next step is the right to keep products working.