The Problem With Technology That Dies With the Company That Made It

A smart device can be beautifully made, genuinely useful and still have a shorter meaningful life than a cheap kettle.

That is not because the battery failed, the sensor wore out or somebody dropped it down the stairs. It is because the company that ran its cloud service changed direction, ran out of money, was acquired, lost interest, or simply vanished. The hardware remains on the shelf, blinking politely into the void, while its essential server has become a historical artefact.

It is one of the stranger bargains we have accepted with connected technology. We buy an object, but often we are really renting permission for it to do its job.

The hidden dependency inside the box

A connected thermostat, camera, tracker, appliance or environmental monitor may look like a self-contained product. In practice, many are only partially functional without a remote service.

The device may need to contact a cloud API to authenticate the owner, download configuration, receive the correct time, process data, send notifications or simply decide whether it is allowed to operate. Some products go further and route routine commands through the manufacturer’s servers. Press a button in your own house, send a request across the internet, wait for a server somewhere else to approve it, then hope your light switches on. Progress has occasionally developed a slightly theatrical relationship with simplicity.

There are valid reasons for remote services. They can provide off-site alerts, shared access, firmware updates, fleet monitoring and storage without asking every customer to become an amateur systems administrator. For a business deploying hundreds of sensors across sites, central management can be valuable.

But a useful service becomes a problem when it is the only route to basic operation.

The physical device may be perfectly healthy. Its microcontroller still runs, its radio still transmits, its sensor still measures temperature or humidity. Yet if its firmware is hard-coded to call api.company.example, and that domain expires or the API is switched off, the product is stranded. Worse, many systems use certificates, signed tokens and online account checks. Even if a technically capable owner could create a replacement server, the device may reject it because it cannot validate the new certificate or signature.

That is not an inevitable law of engineering. It is an architectural choice.

Hardware should outlive a quarterly plan

I have a particular dislike of wasteful design because I know how much practical effort goes into making physical things work reliably. A sensor enclosure has to withstand its environment. A power supply has to tolerate electrical noise. A radio link has to cope with walls, distance and the inconvenient fact that buildings are full of materials determined to spoil Wi-Fi’s day.

When all of that is discarded because a cloud account has been deleted, it feels faintly absurd. Like scrapping a decent car because the garage that sold it has changed its logo.

The cost is not only financial. Consumers lose equipment they thought they owned. Small businesses can lose operational data or monitoring capability at short notice. Disabled people may lose a product that had become part of an accessible routine, perhaps a device used for reminders, security, communication or environmental control. A shutdown notice written in cheerful corporate language does not make that disruption less real.

And there is an environmental cost. Perfectly serviceable electronics become e-waste, while replacement products require new materials, manufacturing and transport. The planet has been asked to absorb rather too many discarded gadgets in the name of “innovation”. It has not, as far as I can tell, sent back a thumbs-up.

A shutdown plan is part of the product

Companies cannot always promise to exist forever. That would be a bold claim from any business, especially one whose office furniture is still held together by optimistic cable ties. Services close. Markets move. Firms fail.

The responsible question is not whether a company can guarantee immortality. It is what happens to customers if it cannot continue.

A credible answer might include:

• Local control for core functions, without an internet connection or vendor account.
• An open, documented local API so owners can integrate or maintain the device independently.
• A supported export format for data, rather than trapping years of readings in a proprietary dashboard.
• Firmware that can be updated locally, with a documented recovery process.
• A commitment to release server code, protocol details or an unlock update if the hosted service closes.
• Clear notice periods and practical migration guidance when a service is being withdrawn.

Not every product needs every feature. A low-cost consumer sensor will not necessarily come with a full self-hosted enterprise platform, and that is fair enough. But it can still report readings locally, continue logging to its own memory, or communicate through a documented standard such as MQTT, Modbus, Bluetooth or a simple local web interface.

The important distinction is between cloud-enhanced and cloud-dependent. Remote access is an enhancement. Losing the ability to turn on the heating in your own home because a distant login service has retired is dependency dressed up as convenience.

What buyers can ask before they commit

Most people should not need to perform an architectural review before buying a doorbell or air-quality monitor. Life is busy enough. Still, a few questions can reveal a great deal.

Ask whether the device works on the local network if the internet is down. Ask whether it needs a subscription or a vendor account for basic use. Look for data export, published APIs and compatibility with established platforms. Read the terms around service withdrawal, although I appreciate that reading terms and conditions is not everyone’s preferred evening entertainment.

For important equipment, avoid a single point of failure. If a temperature alarm protects stock, medicines, server rooms or vulnerable people, make sure alerts have more than one route and that local alarm behaviour does not rely solely on the cloud. An on-device buzzer, relay output or local display can be reassuringly old-fashioned, which in engineering is often another way of saying dependable.

It is also worth considering the company itself. Is its business model clear? Does it sell hardware once while promising unlimited cloud storage forever? That arithmetic has a habit of becoming somebody else’s problem later.

Ownership ought to mean something

Connected products are not going away, nor should they. Properly designed connectivity can make equipment more useful, more accessible and easier to maintain. I am not arguing for a return to dials, paper logs and shouting across the room, tempting though that may be when an app demands its fourth password reset of the month.

I am arguing for products that fail gracefully when the company does not survive. If we have bought the hardware, it should retain useful local function. If our data is stored remotely, we should be able to take it with us. If a service closes, the manufacturer should leave behind a route forward rather than a polite email and a small electronic corpse.

Technology should be built to serve people through the ordinary messiness of life. Companies are not permanent. A well-made device has every chance of being. We ought to let it.