Why Does My Vacuum Need a Cloud?

Illustrations by Storyset

A few days ago, the physical world collided with my digital home. In the middle of a facade renovation, a contractor accidentally sliced the fiber optic cable outside my apartment.

Just like that, the internet was gone.

Not a big deal since I have mobile data, and I know I can use my phone as a temporary "internet provider". So life goes on as normal, right?

The Bedroom Rescue

While the internet was down, my robot vacuum cleaner (Eufy Omni C20) resumed a cleaning session. I had not paid close attention to where it was, but after a few minutes, I realized it was heading straight toward the bedroom where my baby daughter was sleeping.

I pulled out my phone, opened the app, and tried to pause it.

Instead of a controller, the app showed a greyed-out screen: Device Offline.

I figured that maybe it was because my phone wasn't connected to the same network. So, I stopped sharing my mobile data and connected back to my home Wi-Fi. Still offline.

Tension built up. I rushed to the robot and noticed the red LED which indicated the robot wasn't connected. So I had to fish it out from under the bed and manually put it to sleep.

I didn't give it much thought at first and simply tried to reconnect it back to my Wi-Fi. The process failed immediately with a blunt error: Cloud Service Connection Failed. Because the cloud was unreachable, the setup failed to establish a connection and prevented the robot from connecting to the local network.

I landed in one of the Edge Cases that we often talk about in UX design: the offline smart home. Who doesn't have internet at home, right? So why design for a situation that happens "1 in a million times"?

This experience wasn't completely disruptive because I am tech-savvy enough to work around it. But for the average user, this would have been a nightmare - System 2 working at full throttle to debug an issue that was expected not to be there. It was a frustrating and annoyingly poor experience for a device marketed as a piece of high-tech automation.

The Offline Contrast: Design Done Right

Fortunately, not every device in my home was crippled. My smart lights functioned flawlessly.

Why? Because the Philips Hue system was designed with local-first principles. The Hue Bridge handles communication locally over Zigbee and the local network. Even without an active internet connection, my phone could talk directly to the bridge, allowing me to dim the lights, toggle scenes, and maintain control.

The contrast was clear: one system treated the internet as a pipeline, while the other treated it as a leash.

The Fallacy of the Always-Connected Device

Working daily as a UX Designer in a consumer goods company and having spent 10+ years in the industry, I understand the architectural decisions that lead to this. I know the arguments. But as a designer and a user, I am still baffled that these fragile dependencies make it into production.

This problem stems from four core failures in how we design and engineer smart products:

1. Laziness as a Service (LaaS)

Building local network discovery (using protocols like mDNS, SSDP, or local websockets) requires extra engineering effort. It is far easier for developers to route every single event to a centralized AWS or Google Cloud server and let the server push the update back down. This offloads the complexity of local networking from the engineering team to the user's living room.

2. The Data Lock-In Trap

Companies want user accounts, telemetry, and usage patterns. By forcing the device to validate its state with a cloud server before executing a command, they ensure that the user remains logged in and that their habits are recorded. But when this business model bricks the physical product during a common internet outage, the value proposition collapses.

3. The Test-Lab Bias

Designers and engineers test products in pristine environments. They sit in high-speed, corporate offices with redundant internet connections. They do not test what happens when a renovator cuts a fiber line, when an ISP has a routing error, or when the device sits in a dead zone of a house. They treat the internet as a constant, rather than a variable.

4. Lack of Real-World Understanding

The design process often lacks empathy for the real-world contexts in which these devices operate. Designers and Engineers may not consider the physical layout of a home, the presence of children or pets, or the fact that users may not be tech-savvy enough to troubleshoot connectivity issues. This leads to products that are designed for an idealized user and environment, rather than the messy reality of everyday life.

Designing for the Offline Edge Case

In digital product design, we often dismiss network failures as temporary "edge cases." But in physical-digital UX, the stakes are different. An offline edge case in software means a spinning loader. An offline edge case in the physical world means waking a sleeping baby or chasing a robot under a bed.

I take this even more seriously because I work at Dometic (opens in a new tab), an outdoor company. We produce products that the majority of users enjoy out in the woods, with no internet connection. Cloud dependency for Dometic is a death sentence. If we want to build smart products that people can rely on in the most remote and disconnected environments, we must design for the offline edge case as a core use case.

Illustrations by Storyset

The solution is Local-First Design:

• Local Fallback: The cloud should be an enhancement, not a dependency. If a device is on the same local network as the controller, all core operations must execute locally.
• Decoupled Authentication: The device should not require a cloud handshake to verify a simple "stop" command.
• Privacy & Sovereignty: If a device does not require the cloud to perform its physical job, it should not require the cloud to perform its digital job.
• True Ownership: The cloud can shut down and the product must still function. The user owns the product, not the cloud.

Always remember: Any plan works on paper. You can engineer the perfect backend. You can design the best screens. But the real challenge is when you add humans, physical environments, and unpredictable variables. The "edge case" may not be the most common scenario, but it can be the most disruptive.

If we want users to trust smart devices, we must stop building leashes and start building local infrastructure.

Do you want to read more about local-first agentic systems? Check out The Studio of Two Manifesto.