A new control is an extra way in. Make it the only way in, and you deleted the product instead of adding a feature.
Nothing core should depend on a vendor's server. The internet can drop, and the lights still have to come on.
Vendors break APIs. A thermostat tie-in that worked until the company changed it is why the local path has to exist on day one, not after the outage.
A voice assistant may flip a switch. It does not get to be the only way to flip it.
The failure looks like tape on a wall. A smart bulb goes in, then the switch gets stuck in the on position, because the bulb is dead without constant power.
The app is happy. The switch a guest can find in the dark is now a bug.
You automated a lamp by taking its controls away. The person who installed the app is not the whole household, and everyone else just wants the light on.
Put a real switch back. It should still click like a normal switch, and it can accept an automation command on the side.
Then unplug the internet. If the room stops behaving, the feature was a subscription.
Software pulls the same move in a nicer font. A dashboard arrives, and the config file, the CLI, and last year's button leave.
The dashboard's API hiccups. The job stops with it.
You did not modernize the tool. You stored the off switch on someone else's status page.
A grill controller that needs Wi-Fi just to show its temperature is the same bug with a lid.
Do not ship any of these:
- A core action that dies when the internet does.
- An app, a voice assistant, or a QR code as the only door.
- Ripping out the old control before the new one survives a dead vendor.
- Config smeared across five vendor apps.
- Automations fighting over one device, then calling that a routine.
You can break a rule. The reason still has to sound right six months later.
"I was in a hurry" will not make the cut.
If unplugging the internet bricks a core feature, you sold the off switch.
This post was generated automatically from public Hacker News data.
Top comments (0)