Case study
Carers see who needs a drink, right now.
How a smart jug company got a carer app, built in about ten weeks at a fixed price, that turns live jug data into quick actions on the care home floor.
- Client
- Smart Hydration, maker of smart jugs that measure how much care home residents drink
- What we built
- A mobile app for carers, on Android and iOS
- How it was delivered
- Seven sprints at a fixed price, each ending with a live demo
- Delivered
- June 2026
The challenge.
Smart Hydration's jugs measure how much each resident drinks. Managers could see that data in a web portal, but carers on the floor had nothing on their phones to act on it.
The company needed an app that shows who needs a drink right now, makes logging a drink quick, and flags residents at risk.
It also had to work with systems we didn't own: a backend run by a separate team, and live updates from the jugs. Some of the backend the app needed didn't exist yet. And each new jug had to be set up over Bluetooth.
What we built.
- "Who needs me". Residents sorted by urgency, in red, amber or green, refreshed every 30 seconds.
- A page for each resident. The jug's water level, battery and connection, today's drinks against their target, and the time since their last drink.
- Quick drink logging. Pick a drink and a familiar size, such as a mug or a glass. No millilitres to type.
- Refusals. When a resident refuses a drink, the carer records why, from a set list.
- History. A 24-hour chart, and a seven-day average against target.
- Notes and handover. Notes for each resident, and notes for the home that carry into the next shift's handover.
- Jug set-up. A new jug connects in two taps, and the Wi-Fi details are saved for the next one.
- Live updates. Screens stay current as the jugs report in, with a fallback if the live connection drops.
Refusals, the history charts and the iOS version all went beyond what was agreed, at no extra cost.
The hard parts.
- Building against a backend that wasn't finished. Some parts of the backend the app needed weren't ready. We agreed exactly what each part would send, and built against stand-ins, so the app kept moving while the backend caught up.
- The riskiest work first. Bluetooth set-up and live updates were planned early, each with a fallback plan in case the hardware or the backend arrived late.
- Pausing to get the screens right. Once the first version worked, feedback on the design came from several directions. We paused building and ran a workshop with Smart Hydration to settle the screen flow, the status colours and the labels. It cut rework for the rest of the project.
The result.
- About 10 weeks
- to design and build the app, at a fixed price
- 53 features
- each checked against what shipped
- 2 platforms
- Android as agreed, and iOS at no extra cost
- 2 taps
- to connect a new jug
The app was delivered in June 2026, at the agreed fixed price and ahead of the planned care home trial. A delivery report checked all 53 specified features against what shipped, with every change and extra recorded. The design pause, the extra charts, refusal recording and the iOS version all came within the same price.
“We appreciated that they kept the user and the core problem at the centre of the work. They understood our mission, and ensured the conversation and development plans stayed on track to address it.”
For the technical reader
| Layer | Technology |
|---|---|
| App | React Native, Expo, TypeScript, NativeWind |
| Live updates | Pusher, with polling as a fallback |
| Jug set-up | Bluetooth to the jug's ESP32 |
| Delivery | Azure DevOps |
The work started from a feature specification with 13 feature areas, stated assumptions, a risk register and an agreed list for phase two. Where backend endpoints weren't ready, the app used contract-first mock data, swapped for the real endpoints as they arrived.
Not sure which way in?
A first conversation costs nothing. We'll tell you where we'd start, and if the answer is not yet, we'll say so.
Or email info@khiliad.com, or .