AeroGarden, the countertop hydroponic gardens that promised fresh herbs on your kitchen bench, is winding down. The company announced it would cease operations, and owners of its WiFi models were told the controlling app would keep working only for a limited window. It is a small consumer story with a large lesson for anyone buying connected hardware for a classroom: when the brains of a device live in someone else's cloud, the device carries an expiry date you never agreed to.

What happened to AeroGarden

The facts are short. AeroGarden announced it was ceasing operations effective 1 January 2025. For its WiFi-connected models, app access was promised only until March 2026. After that, the cloud service the app talks to is expected to go quiet.

The gardens themselves are not bricks. The lights and pump still run on their built-in timers, so a plant will keep growing. But the smart features, meaning remote control, reminders, firmware updates and anything that routes through the company's servers, depend on infrastructure that somebody has to keep paying for. When the company stops, those features stop with it. The buyer is left holding a device that does less than it did on the day it arrived.

The appliance-plus-cloud trap

This is a pattern, not a one-off. Take an ordinary appliance, add a chip and a WiFi radio, and push the useful logic out to a remote server the owner never sees. The result feels modern and is cheap to ship. It also means the product only works fully while the vendor is alive and willing to run the service. The moment the business model changes, the feature list shrinks.

Cloud dependency is not wrong by itself. Plenty of good tools need a server somewhere. The problem is when core function is held hostage to it: when a garden cannot be scheduled, a toy cannot be controlled, or a robot cannot be programmed without a live connection to one specific company. That is not a feature. It is a countdown.

Why classroom buyers should care

Schools and academies buy differently from households. They buy in sets, they keep hardware for several years, and their budgets are planned a term or a year ahead. A class set of connected devices that quietly loses half its features in the middle of a school year is not a minor annoyance. It is a lesson plan that no longer runs and a purchase that has to be justified twice.

The South African context makes it sharper. Load shedding and uneven connectivity already interrupt any lesson that leans on the internet. If the hardware also needs a vendor's cloud to do its main job, you have stacked two points of failure on top of each other. The safest classroom device is one a teacher can switch on in a room with no WiFi and still run the whole lesson.

What to demand before you buy

You do not need to read a company's balance sheet to protect yourself. A few plain questions at purchase time filter out most of the risk.

• Does the core function work offline? The main job, whether heating, controlling or running a program, should not need the internet at all.
• Is control local? Prefer devices you can drive from the room they sit in, not only through a distant server.
• Can you get your data and work out? Student projects, code and settings should be exportable in an ordinary format, not locked inside one app.
• Can software be installed without the vendor's cloud? Firmware and lesson content that you can load directly will outlive the company that made them.
• Are the standards open and documented? Common connectors, common languages and public docs mean someone else can keep the thing alive.
• What is the plan if the vendor disappears? Spares, a community or open files matter more than a glossy app.

None of this rules out smart hardware. It just moves the smart part somewhere you control.

How we think about it at sheen

Our bias is on the table. The sheenbot∞ board we build lessons around is programmed directly and runs its programs on the device itself. A student writes code in the browser, sends it to the board, and the board keeps doing its job whether or not the internet is there a minute later. Their work is theirs to keep, not a row in a database they cannot reach. You can see the board on the sheenbot∞ page and the kits in the store.

The same thinking shapes how we run classes. Lessons at the Cape Town academy and the holiday workshops assume a room, a set of boards and a teacher, not a permanent connection to any one company's servers. That is a deliberate choice, and the AeroGarden story is a useful reminder of why it matters.

The takeaway

AeroGarden did not fail because hydroponics is a bad idea. It failed as a business, and its customers learned that a cloud-tethered appliance is only rented, never fully owned. For a home cook that is a shrug. For a school with a cupboard full of devices and a year of lessons planned around them, it is a budget risk worth designing out. Buy hardware that still works when the vendor walks away, keep the important logic local, and make sure the work your students do belongs to them.