On September 22, Weber turned off the servers behind the June Oven. Owners had been told in July. The oven sold for as much as $1,500, had a camera inside, and used the app for remote control, recipes, food recognition, and software updates. The app and the cloud are gone now. The oven still heats. It just does nothing smart anymore.

This isn’t a new story. Belkin ended cloud support for select Wemo products on January 31. Bose closed the SoundTouch cloud on May 6. Samsung is retiring its SmartThings Tracker service on October 31. Each one comes with a polite notice and a pointer to something newer. The June case stands out for one reason: Weber looked at open-sourcing the technology and declined, saying the IP was tied to its Weber Connect platform. A co-founder reportedly tried to keep the servers running himself and couldn’t.

We build connected products for a living, so we’ll say it plainly. If you’re about to ship a device with an app, you are signing up for this ending. The only question is whether you planned for it.

The shutdown is a design decision you made years earlier

Nobody at Weber decided in July to brick an oven. The decision was made when the oven was designed so that its app talked to a vendor cloud for everything, including things that never needed a cloud.

Take remote control. If your phone and the oven are on the same network, or within Bluetooth range, a cloud round trip is optional. It’s there because it was the easy path for the team: one backend, one auth system, one way to reach the device from anywhere. Cheap on day one. Expensive on the day the company stops paying the hosting bill.

Now count what the cloud actually carries in a typical product like this:

Only the last one truly needs a server. Everything else can be done on the phone, the device, or the local network. When a product is built that way, a shutdown becomes a loss of convenience features rather than the loss of the product.

What a decent exit plan looks like

We’d put these in the first spec, not the last sprint.

Local control as the primary path. The app should talk directly to the device over BLE or the LAN. The cloud is a relay for when you’re away from home, not the thing that owns the device. This is also better engineering. It’s faster, it works when the internet is down, and it cuts your hosting costs. We go deeper on this pattern in our mobile and connected device app work, where the phone-to-hardware link is the core of the product.

Pairing that doesn’t phone home. Plenty of devices can’t even finish setup without a server. That means a factory reset after shutdown leaves a paperweight. Provisioning should complete offline. Insteon owners learned this the hard way.

Firmware you can sign and hand over. Updates should be signed by a key you control, delivered over any channel, and verifiable by the device. If you ever have to stop hosting, you can publish a final build to a static file host and the app can still apply it.

A documented protocol. This is the part Weber balked at. Publishing your BLE GATT services or local API doesn’t give away your business. Your moat isn’t the byte layout of a characteristic. It’s the hardware, the brand, and the support. Home Assistant has rescued a few abandoned devices, but resurrection stays rare, because most vendors never wrote down how their stuff talks.

A shutdown clause in the product plan. Decide now what you’d do with 90 days of runway: push a last firmware that enables local-only mode, release the protocol docs, and flip the cloud features off in the app before the servers go. It’s a few weeks of work if it’s designed in. It’s a rewrite if it isn’t.

Where we’d push back

Some teams hear this and conclude they should avoid the cloud entirely. That’s wrong. Remote access, multi-user sharing, and fleet analytics are real features, and customers pay for them. A cloud service you operate well is fine.

The line is between features and foundations. A feature can disappear. A foundation can’t, because everything sits on it. Put the device’s core function on the foundation side of the line and keep it local.

We’d also push back on the idea that a notice period fixes anything. Two months of warning, which Weber’s owners got, is better than overnight. But a $1,500 appliance with a 2022 manufacturing end date and a 2026 server end date is still a product that lost its brain in under five years. Buyers are noticing. Reviews of smart appliances increasingly ask what happens when the company goes away, and the honest answer is a selling point or a liability depending on your architecture.

There’s a cost angle for the business side too. Every device you ship with a mandatory cloud dependency is a standing liability on your books: servers, on-call, security patches, and a reputational bill the day you wind it down. Local-first designs shrink that liability. The same instinct drives our local-first software practice, where the user’s data and the app’s core function live on the device.

What to do this quarter

If you already ship a connected product, run a short audit. Unplug your backend in a staging environment and open the app with a real device. List everything that breaks. Sort the list into “needs a server” and “we just never built it locally.” The second column is your roadmap.

If you’re still at the design stage, write the exit plan before the first prototype. It will change the architecture in small, cheap ways: a local API, an offline provisioning flow, a signing key, a protocol doc.

Weber’s customers will keep their ovens. They’ll preheat to 400 degrees and cook a fine chicken. They also paid for a product that was marketed as intelligent, and that part now has an end date. Don’t make your customers discover theirs from an email.

If you’re weighing this for a product, get in touch.