The Case for Local-First Smart Homes: One Engineer's Decade-Long Bet Against Vendor Lock-In

A ten-year home automation build proves that core infrastructure can run without cloud dependencies. The rules are simple, the execution is not, and the vendor incentives push the opposite direction.

Spencer Kittleson's smart home doesn't need the internet to function. That's the founding principle, established roughly ten years ago after Google broke his Nest integration by killing the API. Every core system — lights, garage door, sprinklers, locks, sensors — runs on hardware he owns: Tasmota-flashed ESP boards, an MQTT broker, and Node-RED on a Raspberry Pi. Cloud services like Alexa exist as convenience layers, never as dependencies.

The rules he's codified are worth reading as engineering principles, not lifestyle tips. Rule one: no internet, no problem. Rule two: don't remove the old way while adding the new one — if someone tapes a wall switch so a smart bulb keeps power, you've already failed. Rule three: be agile, because rooms change use and people move in and out. These aren't aspirational. They're constraints derived from real failures, including four scheduled triggers once fighting over the same garden pump. After five years and more residents in the house, a second set of rules emerged. Cloud devices need an API with logs or they don't get installed. Config lives in one place, not five vendor apps. Every device needs more than one way in — app, Alexa, QR code, NFC tag. No batteries unless they last a year between changes. Devices communicate pub/sub over MQTT instead of point-to-point. These rules address the real friction of multi-user homes, not the single-hobbyist scenario most smart home content assumes. The technical stack is deliberately unglamorous. An ESP32 D1 Mini handles custom builds. Sonoff Minis fit inside existing wiring. A Raspberry Pi 4 runs Node-RED and Grafana. LED strips, power transistors, relay modules, resistor assortments, color-coded wire, and a capacitor kit make up the parts bin. The sprinkler controller — a custom PCB with a relay, ESP module, and BME280 sensor — has been running for years without a rewrite. The garage door system grew from a simple cooling flow to a multi-tab Node-RED deployment with Telegram notifications, audio chimes, and Grafana dashboards. The examples of cloud dependency failure are instructive. A Samsung fridge displaying a TLS certificate error on its own screen. A Camp Chef grill controller that requires Wi-Fi to show temperature. An internet-connected printer someone forgot to log out of. These aren't edge cases — they're the inevitable outcome of architectures where the vendor's server sits between the user and the device they paid for. Kittleson's triangle framework — mapping each device across cost, ease, and privacy — is a useful heuristic for anyone evaluating purchases. The wall-mounted tablet dashboard is perhaps the most telling build. It replaced five vendor apps with a single cheap tablet next to the thermostat: garage door, door locks, all lights, brightness, color picker, warm-to-cool temperature control. Everyone in the house uses it. The smart locks accept a password, the app, a keycard, or a regular key. Multiple entry points aren't a luxury — they're the only way multi-user homes actually work without someone becoming unpaid IT support. This is a practitioner's report, not a product review. The value is in the pattern: local-first architecture with cloud as optional overlay, pub/sub messaging over point-to-point, multiple interfaces per device, and rules that survive contact with other humans. The question is why this approach remains the exception rather than the default — and the answer is that vendor incentives point directly away from interoperability and local control.