Case Study — Hydrotherapy Control System
Twenty Years of Systems Discipline. Thirty Days to Production.
We paired two decades of experience building software that isn't allowed to fail with AI-accelerated engineering to take a hydrotherapy device from concept to a production-grade Android platform — native hardware control, cloud sync, and a full clinic workflow included — in under a month.
- Systems engineering
- 20+ yrs
- Concept → production
- <30 days
- Stack
- ESP32 + native Android
- Build
- AI-accelerated
- Year
- 2025
- Services
- Firmware integration, Native Android, Cloud sync, AI-accelerated delivery
A hydrotherapy device isn't a toy. It runs water through a machine wired to a patient, on a timer, watched by a therapist who needs to trust every number on the screen. Our client needed a tablet-based control system for exactly that kind of device — and needed it fast enough to get real clinics running before the opportunity window closed.
01 — The Challenge
A Medical-Adjacent Device, a Fragile Foundation, and a Month on the Clock
The physical machine — the part patients are actually connected to — is run by an ESP32 microcontroller. Everything else was ours to build: a tablet app for therapists to manage patients, run live sessions, and watch real-time telemetry; a way to control the machine's hardware safely; and a business model wrapped around all of it.
- 01
A brittle pairing model
The ESP32 ran as its own WiFi Access Point with a fixed SSID and password — the tablet had to find and join it manually, every time, in a busy clinic.
- 02
A licensing engine, wired into hardware
A Demo Mode was required: a limited number of trial sessions, after which the device locks until a supplier upgrades it to Full Mode.
- 03
Zero tolerance for "usually works"
A session dropping mid-therapy isn't a bug report — it's a patient standing next to a machine that stopped responding.
02 — Our Approach & the Technical Journey
Three Attempts, One Real Architecture
Good engineering here wasn't about writing more code, faster. It was about recognizing, quickly, when an approach had hit a genuine ceiling — and pivoting before it cost us weeks we didn't have.
Dead end
PWA + mDNS Discovery
We started where most teams would: a Progressive Web App built in Ionic React, with the ESP32 advertising itself over mDNS so the tablet could find it automatically. It worked cleanly on our own hardware — and broke unpredictably across the mix of Android tablets clinics actually use. mDNS resolution proved too inconsistent to put in front of a therapist mid-session.
Dead end
IP Relay via an In-Browser Server
Plan B was IP-based: have the ESP32 report its address to a small server running inside the PWA itself, reachable at the tablet's own hotspot gateway IP. On paper it closed the discovery gap. In practice it hit a hard platform wall — browsers are sandboxed by design and simply cannot host a listening server. That's a boundary, not a bug, and no amount of clever code gets around it.
Breakthrough
The Pivot: Native Android via Capacitor
Recognizing the ceiling early, we moved the client off the web platform entirely, rebuilding it as a native Android app with Capacitor. That single architectural move unlocked what the browser never could: the tablet creates its own WiFi hotspot, the ESP32 joins it in Station Mode, and the two now talk over a connection the app fully owns — live sensor telemetry flowing in, hardware commands flowing out, no router and no discovery protocol left to fail.
Before — PWA in browser
After — Native Android (Capacitor)
Two dead ends the client tried to reach the machine from inside a browser, both stopped by real platform boundaries — and the native rebuild that finally gave the app a connection it fully owns, in both directions.
This is where twenty-plus years of building systems that have to just work pays for itself — knowing which failure is a symptom worth debugging, and which one is a wall worth walking around. AI-accelerated development gave us the raw velocity to rebuild the client natively, wire up the hotspot-to-station handshake, and re-implement every screen in days rather than weeks. But the judgment to spend that velocity on the right rebuild, at the right moment, is what kept a one-month timeline realistic instead of reckless.
03 — The Solution
One Connected System, Not a Pile of Screens
The finished architecture keeps the hardware deliberately dumb and puts every ounce of intelligence — and every business rule — in the app.
ESP32 — Thin by Design
Station-mode WiFi client only. Reads temperature, water level, and pressure; drives the heater, pump, flush, and blower. No business logic on the device — nothing to update in the field.
Android App — The Brain
Hosts the hotspot, runs the live control loop, and manages therapists, patients, and the full session lifecycle — Prepare, Start, Pause / Resume, Flush, End.
Offline-First by Default
Local storage backs every session with cloud sync layered on top, so a dropped connection mid-therapy pauses gracefully instead of failing outright.
Demo — Full Licensing, Built In
Session counting, an app-lock screen with the supplier's own contact details, and a Supplier panel that can extend a demo or activate Full Mode remotely — a technical constraint turned into a working sales tool.
04 — Design Evolution
From "Show Everything" to "Show What's Needed"
The early concepts followed the brief closely — a classic engineer's-eye dashboard, every metric and every gauge on screen at once. Good instinct for coverage; wrong instinct for a therapist standing at a tablet mid-session.
The prototype put six live readouts, a tank graphic, and a full sidebar in front of the operator before they'd even started a session. Production distills that same coverage into four unambiguous destinations — Therapy, Therapy Logs, Settings, Resources — with the machine's serial number and connection state fixed in the header, always visible, never buried in a sidebar.
Threshold configuration moved out of a standalone Control Panel and into the moment it's actually needed. The therapy flow itself replaced raw sensor jargon with the plain three-step language therapists and patients actually use — Hydrate, Soften, Evacuate — with machine connection state confirmed before a session can even begin.
Early role-and-permissions thinking became a straightforward, searchable Manage Therapists / Manage Patients list — the access-control problem solved once, structurally, in the backend, rather than surfaced as another screen for the operator to configure.
New in Production
Demo Mode wasn't in the original screen list — it's the licensing engine described above, given a face: a lock screen that tells the therapist exactly why the device stopped, and exactly who to call.
New in Production
And on the other end of that phone call: a Supplier panel where extending a demo or activating a machine is two clicks, not a support ticket.
05 — Key Results & Impact
What Shipped, in Under a Month
<30
Days, concept to production-grade build
Firmware through supplier panel
0
Web-platform dead ends left in production
Rebuilt native, not patched around
3
Connected tiers shipped as one system
Owner app, supplier panel, admin console
100%
Session-safe
Therapy pauses and resumes through connectivity drops
06 — Why This Matters
Judgment, Applied at AI Speed
Most "AI-accelerated" delivery stories are about typing faster. This one is about a team that has spent twenty-plus years learning exactly where systems break — connectivity, hardware boundaries, real clinic conditions — and now has the tooling to build around that judgment at a speed that used to be impossible.
That combination is what let a medical-adjacent device go from a whiteboard sketch to a machine running real therapy sessions in under a month, without cutting the corners a device like this can't afford to cut.
Hardware Integration · Native Android · Cloud Sync · AI-Accelerated Delivery
Building something that has to be reliable?
Talk to a senior engineer about AI-accelerated delivery or a production RAG / agent system. We work with teams across the US, Canada and beyond.
Book a Discovery Call