It stopped working on a Tuesday. No error message, no notification — just a blank app where the irrigation schedule should have been, and a lawn that wasn't going to water itself. The cloud-connected sprinkler controller I'd paid $100 for, and had been paying $29 a year to keep running, had lost its connection to whatever backend server it depended on.
I ran through the usual troubleshooting. Power cycle, factory reset, device re-pairing. Nothing worked. The support forums were full of the same complaint with no resolution. The company had changed something in their infrastructure, and older devices had been left behind. The hardware wasn't broken — it had simply been switched off remotely, without notice, by a vendor whose roadmap no longer included me.
The hidden cost of “smart” hardware
Consumer IoT runs on a specific model: sell the hardware cheap, recoup on the subscription. The device is the hook; the recurring fee is the business. The $100 controller felt like a reasonable upfront investment. The $29 annual fee felt like a fair trade for automatic weather adjustments and remote access. What I hadn't fully priced in was the dependency that combination created.
The app worked, mostly. But it was clearly designed to sell more than it was designed to work. The home screen pushed premium plan upgrades. Notifications surfaced features I wasn't paying for. And underneath the sales layer was a feature set that had barely evolved in years: eight zones maximum, three irrigation programs, weather integration that amounted to a rain-skip toggle with minimal configurability.
The subscription wasn't paying for development. It was paying for access — access to a server that sat between my controller and my valves. Without that server, the hardware was an inert plastic box.
The uncomfortable truth: You don't own a cloud-dependent device. You lease it — and the landlord can leave without notice.
The alternative I didn’t know I could build
I had a Raspberry Pi 3B sitting in a box in the closet for seven years. I also had a clear picture of what I actually wanted: a local web interface, unlimited zones and programs, weather-based rain delay, and nothing that required a third-party server to function. The question was whether I could build it — as a networking engineer, not a software developer.
A $12 SunFounder eight-channel relay board arrived from Amazon two days later. I flashed Raspberry Pi OS Lite onto a microSD card — the headless, 64-bit version with no desktop environment, just an SSH server and a clean Linux foundation. Total out-of-pocket for new hardware: twelve dollars.
From the Pi’s terminal, I opened Codex CLI and described what I wanted: a Flask web application to control irrigation zones through GPIO relay outputs, with a weekly scheduler, zone naming, and weather integration through a free public API. I wasn’t writing the software. I was describing a problem in plain language. Codex wrote the software.
I’m a networking engineer. I can read code and reason about systems, but building a production-grade Flask application with a proper systemd service, a hardware abstraction layer, and a weather API integration from scratch would take me weeks, not a weekend. Codex closed that gap.
What came out the other side
What Codex produced wasn’t a prototype. It was a production-ready application.
What the finished system delivers
The commercial controller had three programs. This one has as many as you want.
The real cost comparison
When you put the two systems side by side, the gap isn’t just in features.
| Dimension | Commercial controller | DIY Pi + Codex |
|---|---|---|
| Upfront cost | $100 | ~$12 (relay board) |
| Annual cost | $29/yr subscription | $0 |
| Zones | 8 (hard limit) | Unlimited |
| Programs | 3 | Unlimited |
| Weather integration | Basic rain skip | Open-Meteo forecast, configurable threshold |
| Cloud dependency | Required | None — fully local |
| Failure mode | Vendor outage = no control | Self-hosted = full visibility |
| Data ownership | Vendor’s servers | Your device |
| UI | Sales-driven, bloated | Purpose-built for the task |
What this actually means
This isn’t a story about sprinklers. It’s a story about a threshold that AI coding tools have crossed — one that meaningfully changes what’s possible for technical people who aren’t professional software developers.
What I built is not a toy. It’s a production-ready Flask server running under a systemd service, with rotating file logs, a hardware safety layer that forces all relays off on startup and shutdown, a max-runtime timer to prevent runaway zones, and weather integration through a free public forecast API. It took a weekend, a twelve-dollar relay board, and a computer that had been collecting dust for seven years.
The implications for how technical organizations evaluate software decisions are real. SaaS vendors have always had a structural advantage in the buy-vs-build argument: custom software is expensive and slow to produce. AI coding tools are eroding that advantage — not for every problem, and not without technical judgment to guide them, but meaningfully, for well-scoped problems where requirements are clear and the domain owner understands what good looks like.
The best solutions are often the ones you control completely. That’s true for cloud architecture. It turns out it’s true for sprinkler systems too.
Thinking about where vendor dependency is creating risk?
Whether it’s a SaaS tool, a cloud platform, or a piece of hardware with a subscription attached — if a vendor going dark would take a system with it, that’s worth a conversation.
info@acendri-solutions.com