The Hidden Cost of Making Every Product Dependent on an App

A surprising number of ordinary things now arrive with an implied second component: your phone. A light bulb, a thermostat, a coffee machine, a lock, a washing machine, a set of scales. Sometimes the app genuinely adds something useful. Often it is simply standing between you and a button that used to work perfectly well.

I am not arguing for a return to a world of mechanical timers and instruction manuals printed in type small enough to qualify as a medical test. Good software can make products more accessible, more informative and easier to configure. For some people, particularly disabled people, app control can be far more than a convenience. It can be the difference between independently adjusting something and having to ask for help.

But making every function dependent on an app has a hidden bill. It is paid in reliability, privacy, accessibility, long-term ownership and, occasionally, the peculiar indignity of needing a software update before one can make toast.

Convenience is useful, right up to the point it becomes compulsory

There is a sensible distinction that manufacturers regularly blur. An app can be an optional interface, offering schedules, notifications, diagnostics or remote access. Or it can be the only route to basic use.

The first approach respects the fact that products have physical homes, physical users and physical failure modes. A heating controller should still let someone set a temperature at the device. A smart lock should still provide a dependable local method of entry. A kitchen appliance should not become a decorative plastic monolith because a cloud account cannot be reached.

The second approach converts ownership into a continuing service relationship. You have bought the hardware, but essential parts of its operation sit behind a login, an app-store account, a phone operating system, an internet connection and the manufacturer’s continued interest in supporting all of the above. That is rather a lot of eggs for a light switch to be carrying.

Manufacturers favour the model because apps provide a direct customer channel, behavioural data, opportunities for subscriptions and a tidy way to change the product after sale. Some of those things can be beneficial. Firmware updates can fix genuine defects. Remote diagnostics may prevent wasted visits. Usage data, collected carefully and with meaningful consent, can inform better design.

None of that makes app-only control an inevitable design choice.

The engineering problem is not theoretical

Every dependency adds another way for a system to fail. This is basic engineering, not nostalgia dressed as a rotary dial.

Consider a device that needs to be commissioned through a mobile app. The chain may include Bluetooth pairing, local Wi-Fi credentials, DNS resolution, a manufacturer API, account authentication and a push-notification service. If the device uses cloud-mediated control, a command from your phone may leave your house, travel to a remote service, return through your broadband router and finally reach the device sitting three metres away.

That is an impressive route for turning on a lamp. It is also fragile.

A router replacement can break locally stored credentials. A changed Wi-Fi band can stop older devices reconnecting. A phone update can remove a permission the app quietly relied on. An expired certificate, an overloaded authentication service or a discontinued API can turn working hardware into something with the practical usefulness of a mildly expensive paperweight.

There are good technical alternatives. Local control can remain available when the internet is down. A device can expose physical controls for core functions and reserve the app for enhanced features. Products can use documented local protocols rather than routing every action through a vendor cloud. This takes more design effort, testing and support discipline. That is the point. Resilience does not happen because a marketing slide says “smart ecosystem”.

For safety-adjacent products, the question should be even sharper: what happens when the app, account or cloud service is unavailable? If the answer is “the customer cannot operate the product”, someone has designed a dependency, not a feature.

Accessibility cannot be an afterthought bolted to a login screen

App control can be genuinely liberating. Voice control, larger text, switch access, screen-reader support, personalised layouts and remote operation can make a product usable for people who may find fiddly controls, inaccessible displays or physical reach difficult. That matters, and it should not be dismissed by people who happen to enjoy tiny capacitive buttons.

Yet app dependence can create fresh barriers just as quickly.

An app may not work properly with a screen reader. It may demand a gesture that is difficult for someone with limited dexterity. It may require a recent and expensive phone. It may assume users can complete a multi-step account verification process, read a visual pairing code or recover access after changing their number. None of those assumptions is harmless.

The most inclusive design is usually not one interface replacing another. It is more than one reliable way to do the important thing. Physical controls, a clear local display, accessible app support and, where appropriate, voice or remote interfaces give people options.

There is a tendency to call phone control “accessible” because most people own phones. That is a category error. Possessing a device does not guarantee that every app, account flow, payment requirement or update cycle is accessible to every person. A wheelchair ramp is not made universally accessible by placing a password prompt at the bottom of it.

Ownership should survive a manufacturer losing interest

The uncomfortable question for any connected product is simple: what happens when the company stops operating the service?

Businesses are acquired, pivoted, restructured and occasionally evaporated. Product lines are discontinued. Cloud platforms are retired because ongoing hosting, security maintenance and customer support cost money long after the launch campaign has used up its cheerful stock photography.

When that happens, customers should not lose the basic function of something they have already purchased. A thermostat should remain a thermostat. A lock should remain a lock. A sensor should still be capable of reporting a reading locally, even if the original dashboard has gone to join the great SaaS graveyard in the sky.

This is especially important for monitoring and control systems. Sensors do not become less real because a subscription expires. Temperature, humidity, power consumption and door status continue their stubborn existence regardless of a vendor’s quarterly strategy. If a product only lets you see your own locally generated data through its cloud, you do not fully control the product or the information it produces.

Buyers can ask useful questions before committing: Does it work without the internet? Can core functions be used without an account? Is data available locally or exportable in a documented format? What is the company’s support policy? Is there a physical fallback?

The answers may not always be reassuring, but at least they are answers.

A better standard: app-enhanced, not app-captive

The app is not the villain. Badly considered dependency is.

A well-designed connected product should continue delivering its essential purpose during an internet outage, after a phone upgrade and if the manufacturer eventually withdraws its service. The app should make the experience richer, not hold the keys to it. It should be possible to configure a product without handing over more personal information than the task requires. And access should not depend on every household member sharing one person’s phone like a very small, very expensive family heirloom.

For manufacturers, this means treating offline operation, local control and accessibility as product requirements rather than awkward exceptions. For buyers, it means rewarding products that retain useful physical controls and clear failure behaviour, even when the packaging is less keen to promise an “intelligent lifestyle”.

Technology earns its place when it removes friction without quietly replacing it with dependency. A product that works on its own is not less modern. It is simply better prepared for the perfectly ordinary day when Wi-Fi goes down, a phone battery dies, or an app decides that accepting revised terms is somehow urgent at 7:12 on a Tuesday morning.