> Eight Sleep's system, which relies on backend servers for everything from real-time adjustments to data syncing, had no fallback. "It's unacceptable," fumed one early complainant on X, echoing the frustration of many who shelled out for "seamless" smart sleep only to face analog purgatory.
I'm guessing that this is a typical "smart" device setup where the cloud is essentially a tunnel between the app and the device that also saves a copy of all transmitted state for backup and data mining. The simplest design from the company's POV, but the worst design for resilience.
The real question: Was this an explicit or implicit product decision? ie, was it an explicit PM decision that local comms didn't match product requirements, or did they outsource it to the lowest bidder and have no idea this was a ticking time bomb, or did eng have to cut features to make some deadline, etc? If Eight Sleep doesn't have an at least an internal postmortem then someone should lose their job.
As a user, I would prefer the devices communicate locally and use a cloud tunnel only as backup. But this means engineering has to support two communication stacks, which is obviously more expensive than one. And the local network option is probably harder to build since cloud-based has so much tooling available.
My baseline expectation - that I can't believe I'm actually typing out - is that an appliance should operate as expected without Internet access. My only smart device is a door lock because a PIN is easier than a house key for our lifestyle, but even that isn't connected to Wi-Fi.