Stop Making Everything an App
I bought a lamp.
A lamp is a mature technology. We have considerable institutional experience with lamps. Electricity enters. Light comes out. Civilization has tested this architecture extensively.
The box contained a QR code.
That was the first warning.
The lamp wanted an application. The application wanted an account. The account wanted an email address, a password, acceptance of terms, permission to send notifications, permission to discover nearby devices, and access to Bluetooth. Then the lamp required a firmware update before it would perform the advanced computational task of becoming brighter when I pressed a button.
I had owned it for eleven minutes.
Somewhere between fire and Wi-Fi, lighting became administration.
I am saying this as a person who likes automation. I build systems specifically because pressing the same six buttons every day feels like an insult from time itself. Connected devices can be useful. Apps can be useful. Accounts can be useful.
We have simply reached the stage where useful ideas are being applied to objects that were doing fine.
FEATURE REQUIREMENTS: LAMP
Let us examine the product specification.
Required behavior:
Produce light.
Useful optional behavior:
Adjust brightness. Change color temperature. Maybe remember the last setting.
Potential connected behavior:
Schedules, remote control, integration with a larger home-automation system.
Fine.
Now compare that with the implementation.
Dependencies:
Phone application. User account. Vendor cloud. Bluetooth pairing. Internet connectivity for some functions. Firmware service. Authentication service. Push-notification infrastructure. Mobile operating-system compatibility. Whatever analytics package is hiding in there pretending it needs to know how enthusiastically I use beige.
We have turned a light source into a distributed system.
Distributed systems are famous for one important property: eventually you get to debug all the computers at once.
A wall switch had an exceptional uptime record.
The account is often where the nonsense begins
Accounts make sense when the service needs persistent identity.
Email needs an account. Cloud storage needs one. A banking application definitely should know who you are. A collaborative project system benefits from remembering which person deleted the database schema and then went mysteriously offline.
My kitchen scale has weaker arguments.
If a device can perform its main function locally, account creation should require a real reason. Synchronizing data across devices may qualify. Remote access may qualify. Paid services may qualify.
“Marketing would like an email address” does not qualify from my side of the transaction.
Every mandatory account creates work. Users have another password, another privacy policy, another breach surface, another database containing personal information, another recovery process, and another service that may eventually email them about “exciting changes to our terms.”
The manufacturer gets work too. Authentication has to be maintained. Password resets have to function. Data needs protection. Account deletion has to mean something. Security incidents now involve customer identity rather than malfunctioning lamps.
Congratulations. Your kettle has governance.
Was the tea worth it?
Apps have become packaging for features that already had interfaces
The physical control is disappearing from devices that already possessed an excellent physical control.
Button.
Buttons are underrated.
They have low latency. Discoverability is strong. Authentication requirements are modest. They function during internet outages and usually offer excellent cross-platform compatibility with fingers.
Then someone removes the button and replaces it with an app because the app feels modern.
Now changing a setting requires finding the phone, unlocking it, opening the correct application, waiting for connection, navigating to the device, and hoping the operating system has not quietly revoked the Bluetooth permission since last Tuesday.
The task has acquired steps.
That matters because usability is partly the distance between intention and effect.
If I am standing beside the fan, I should be able to change the fan.
If I am touching the washing machine, I should be able to start the washing machine.
If I need to find my phone to operate the object physically touching my hand, somebody should have to defend that design in a room containing witnesses.
Remote control can coexist with local control. Software can extend hardware without replacing every useful affordance the hardware already had.
Please leave the button.
I promise the button will not damage your innovation strategy.
Notifications are breeding
Once an object has an app, it eventually discovers notifications.
The washing cycle finished.
The robot vacuum finished.
The air purifier changed mode.
The toothbrush has insights.
The oven reached temperature.
The refrigerator door was open.
The refrigerator door is now closed.
The coffee machine would like maintenance.
The scale has identified a trend and apparently feels we should discuss it.
Every connected product becomes convinced that its internal state deserves a place on my lock screen.
It does not.
Notifications should compete for attention according to consequence. Smoke detector: yes. Water leak sensor: definitely. Front door unlocked unexpectedly: useful. Dishwasher successfully completed the job described in its name: I had faith.
The problem is partly technical and partly cultural. Once an app exists, product teams gain a communication channel. Communication channels develop ambitions.
What began as device control becomes reminders, tips, feature announcements, subscription offers, streaks, achievements, weekly summaries, recommendations, and requests to rate the application that controls the object you already bought.
The appliance has become needy.
Get Franziska "Ziska" Fink’s stories in your inbox
Join Medium for free to get updates from this writer.
I preferred it when the toaster processed its feelings privately.
Software creates an expiration date hardware did not need
This part bothers me more.
Simple hardware can remain useful for decades. Connected hardware inherits the lifespan of its software dependencies.
The device may still work electrically while the app disappears from the store. The operating system may stop supporting it. Certificates expire. APIs are retired. Cloud services close. The manufacturer is acquired. Authentication breaks. A server nobody knew the product depended on gets switched off.
The physical object sits there, perfectly healthy, waiting for a remote computer that no longer exists.
That is an absurd failure mode for a lightbulb.
Before adding mandatory software to hardware, product designers should ask what happens ten years later. Can the device still perform its primary function? Can it be reset? Can another controller talk to it? Is the protocol documented? Does local control survive the vendor?
A connected feature can reasonably expire.
The chair underneath it should not.
Ecosystems are nice until you own five
Each company would like its own ecosystem.
This sounds pleasant when you own one company’s devices. Everything appears in one interface. Automations work. Setup is consistent.
Then reality shops around.
The bulbs use one app.
The cameras use another.
The thermostat has its own account.
The robot vacuum belongs to a platform whose icon you cannot distinguish from the air purifier’s.
The door lock uses a bridge.
The bridge has an application.
The application has a plugin for the larger automation platform.
The larger automation platform recently renamed rooms to “spaces” for reasons I assume involved a workshop.
Now the home has infrastructure architecture.
Someone becomes administrator.
Someone else presses a switch and asks why the hallway has stopped participating.
Interoperability standards help. Local protocols help. Open APIs help. So does the radical idea that an object might perform useful work before joining an ecosystem.
Products should earn integration through the problem they solve. Integration itself is not a benefit if the original task was already easier.
Sometimes the correct software architecture is none
This is difficult for software people.
We like software.
Give us a mundane problem and our brains immediately begin assigning states, events, interfaces, and possibly a small database.
I understand.
But software introduces failure modes. Updates. Security. Maintenance. Dependencies. Support. Compatibility. Data handling. User education.
Those costs may be worth paying.
A parking meter benefits from digital payment.
A medical device may benefit enormously from remote monitoring.
Industrial equipment can gain real value from telemetry and predictive maintenance.
A €12 kitchen timer does not automatically need a user identity and a cloud region.
Sometimes a mechanical switch already solved the problem.
Sometimes a local web interface is enough.
Sometimes Bluetooth is enough.
Sometimes the existing operating system can provide the interface.
Sometimes the user needs one configuration page during setup and will never need software again.
And sometimes the product should contain a knob.
Knobs remain devastatingly competitive technology.
Delete the app in the design meeting
Here is a test I would like more teams to run.
Design the product.
Then delete the app.
What stops working?
Anything essential?
Good. Now you know what the software actually contributes.
If removing the application destroys the product’s main purpose, ask whether software genuinely enables that purpose or whether the design moved basic functionality into software simply because software was available.
If the app mostly provides optional capabilities, excellent. Make those capabilities optional.
If the account mostly enables synchronization, let users who do not need synchronization skip it.
If cloud access mostly enables remote control, preserve local control.
If notifications mostly exist because somebody added notifications, introduce that person to silence.
You may discover that the app has a legitimate job.
You may also discover that the product team has spent eight months building an identity platform so someone can adjust a lamp from three metres away.
Both discoveries are useful.
My lamp works now.
I created the account. Installed the update. Disabled three notification categories. Removed one unnecessary permission. Discovered that local control becomes unreliable if the application has not connected recently, which is a sentence about lighting that should make engineers uncomfortable.
There is still a button on the power cable.
I use that.
The application keeps offering features.
The button has never emailed me.
