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 five 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, MQTT, 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 development 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.

5. Zero Empathy for the User

The most unhinged of all. Sometimes driven by ego, sometimes driven by greed, sometimes driven by cost, sometimes driven by ignorance. The issue is clear but ignored. When a device fails due to a cloud dependency, the user is left with a non-functional product and no clear path to resolution. The user is left stranded, confused, and frustrated. This lack of empathy for the user’s experience during failure states is a critical oversight in the product development process.

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 , an outdoor company. We produce products that the majority of users enjoy out in the woods or in the middle of the sea, 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 Local-First Design

Balancing the Business with the User is challenging, but not impossible. We can design for the user without sacrificing the business goals. It requires a shift in mindset and architecture, but it is essential for building products that users can trust and rely on.

Human centric should always be the north star, and the technology should be the tool to achieve that. If the technology is getting in the way of the human experience, then it is the technology that needs to change.

Technology should never drive the experience. The experience should drive the technology. If the design requires a local-first experience, then the technology must support it.

Only Safety and Sustainability can justify a cloud dependency. If the cloud is required for safety reasons (e.g., remote monitoring of critical health devices) or sustainability reasons (e.g., optimizing energy usage based on real-time data), then it can be justified.

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.

Removing the cloud dependency creates a clear distinction between “offline mode” and “online mode,” where the device can function independently of the internet, and the cloud serves as a backup for remote access and advanced features.

It is easier for the user to see the real value of the cloud and prevents the company from creating a gimmick that only confuses and frustrates users.

Decoupled Authentication

The device should not require a cloud handshake to verify a simple “stop” command. If authentication is required, the device should enforce it locally, either by the device itself or via a local hub. This way, the user can maintain control over their device even when the cloud is unreachable.

It reduces latency and increases reliability, while reducing API calls and unnecessary traffic to the cloud. It also allows for more secure authentication methods that do not rely on the cloud, such as local PIN codes or biometric authentication.

It increases user’s perception of privacy and control, as they are not forced to share their data with a third-party cloud service just to use basic functionalities of their device.

Untethered Experience

If a device does not require the cloud to perform its physical job, it should not require the cloud to perform its digital job. A cloud dependent feature should be an optional enhancement, not a mandatory requirement. The user should be able to choose whether to use the cloud features or not, without sacrificing the core functionality of the device.

The limitation of the cloud should be clear to the user, and the value of the cloud should be clear as well. The user should not feel like they are missing out on essential features if they choose to use the device without the cloud.

Building confidence and trust in the product is crucial, and an untethered experience allows users to feel in control of their devices, rather than feeling like they are at the mercy of an unreliable cloud connection. It empowers the user to make informed decisions about their technology and promotes a more inclusive and accessible design that does not exclude users who may not have reliable internet access or who prefer not to use cloud services.

True Ownership

The cloud can shut down and the product must still function. The user owns the product, not the cloud. The user should have the ability to use, maintain, and repair their device without relying on the cloud. This includes access to local APIs, local storage, and local control interfaces that do not require cloud connectivity.

It increases the loyalty and satisfaction of users, as they feel a sense of ownership and autonomy over their devices. It also promotes sustainability, as users are more likely to keep and maintain their devices if they can use them without relying on a cloud service that may eventually shut down.

It shows a commitment to the user and to the longevity of the product, rather than a focus on short-term profits from cloud services. It also encourages a more ethical approach to technology, where the user’s rights and needs are prioritized over the company’s desire for data and control.

Conclusion

Treat the cloud as a feature, not a foundation. The cloud can enhance the user experience, but it should never be the only way to access the core functionality of a product. By designing for the offline edge case and prioritizing local-first principles, we can create products that are more reliable, more trustworthy, and more user-centric.

Overcoming the 9x barrier of adoption requires us to design for the real world, not just the idealized one. It requires us to consider the unpredictable variables that can disrupt the user experience and to build products that can withstand those disruptions.

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.