First, Im questioning whether smart beds should exist. But let's assume there's a use case for them, shouldn't the maker of these beds ensure that they don't malfunction if they have no connection? I'd hold the company that produces these smart beds liable first of all.

Then, you would be able to avoid paying their subscription ;)

Discussion: https://news.ycombinator.com/item?id=45658056

And an update: https://news.ycombinator.com/item?id=45677351

This is what happens when pure software people, with no hardware experience/education, do hardware for the first time. I've seen it multiple times, including in robotics. The mindset can be too far disconnected from real world consequences, especially those of electrons doing their thing.

In this case, the problem seems to be a complete disconnect from reality itself, at the decision making level of the company. I'm guessing many of an engineer there are saying "told you so".

I'm not sure I agree with this take.

We're software people who have gotten into hardware, and we're in the sleep space as well.

Our tech was designed to work completely offline, not really for this type of situation, but just because you never know when someone won't have ble.

Of course, it's not some hard rule. But it's very very consistent, in my experience, with all the pure software people who have come to work in all the hardware groups I've been in, throughout my career.

> but just because you never know when someone won't have

And, with that, you've shown mindset was not too far disconnected from reality. Now imagine not considering that someone may not have a constant internet connection, and you get this company, and closer to what I usually see.

edit: related, we have some air gapped systems. and wow do peoples brain implode with that constraint. from what I can tell, the whole concept of using/deploying compiled binaries/libraries is becoming a lost art.

If you're starting a company like this, hire a seasoned firmware engineer and make sure they have decision making power, and an adversarial relationship with the cloud team.

Funny, as a software person I feel like the last thing I would want to do is depend on software to move a hardware component - I’d always want some sort of physical, manual, mechanical fallback.

>I'm guessing many of an engineer there are saying "told you so".

I'd guess not, because they're still working there.

I would say inverse is true too. Hardware companies producing software also end up with shit software. It's as if it requires different mindsets. Not many companies get both right.

I see the usual accelerationist playbook: Create happy path (minimize cost/time to market) -> sell happy path -> use income to fix other paths (or crash and burn)