Consumer IoT · 5 sprints to MVP
Shipping a wearable app before the wearable existed
A child-safety product whose hardware was not ready. We built the MVP against a mocked device contract instead of waiting, and shipped without the usual collapse when real constraints arrived.
- Estimates that settled the platform choice
- 312 vs 499Estimates that settled the platform choice
- Foundation to demonstrable MVP
- 5 sprintsFoundation to demonstrable MVP
- Hardware dependency off the critical path
- Mocked-firstHardware dependency off the critical path
The problem
A caregiver app for a child-tracking wearable, where the wearable itself was still a prototype and the hardware partner’s interfaces were not available. The default paths were both bad: wait indefinitely for hardware maturity, or build a convincing demo that falls apart the moment real device behaviour — battery limits, update intervals, connectivity gaps — turns up. Meanwhile a platform decision was open, with native and cross-platform estimates far enough apart to change the budget.
What I did
I ran a discovery that separated confirmed facts from assumptions and from genuine unknowns, then built the MVP API-first against a mocked device contract agreed with the hardware partner — so real integration became a swap rather than a rewrite. The estimate comparison settled the platform question on evidence: cross-platform came in at roughly 312 units against 499 for native, and the decision was recorded with its reasoning. Most importantly, the product was designed to be honest about data age: freshness indicators, last-known timestamps, and an explicit stale state, rather than a real-time promise no wearable could keep.
How it ran
- 01
Discovery
Facts, assumptions and unknowns separated explicitly — including what the hardware could actually do versus what had been wished into existence. Out-of-scope was written down, because small features travel in packs.
- 02
Contract first
The device event contract and the mobile-to-backend API were agreed and frozen before integration work widened, with mock payloads and defined error and stale states.
- 03
Foundation
Auth, internationalisation, data schema, map readiness and mocked device flows — deliberately setup rather than feature breadth.
- 04
The safety loop
The one journey that had to be reliable: critical alert opened, child and device context shown, location and its freshness understood, follow mode entered and exited without freezing or faking currency.
- 05
Stabilisation and handover
QA against stale, offline and delayed states as first-class scenarios, an analytics event set for the core flows, and a hardware validation plan for the prototype cohort.
Other work
All case studies →- Healthcare
A hospital field app that works without signal
Multi-tenant iOS app for clinical staff, built offline-first because the corridors it runs in have no reliable connectivity.
- HealthTech
Conversational onboarding for a consumer health app
A health app where the intake interview is an AI conversation rather than a twelve-page form, with scoring built on connected platform data.
- Aviation
One device, three roles, one signature
A paper handling process where a tablet passes from a ground agent to a flight captain and back. I prototyped the handover itself, because that is the moment the process either works or does not.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.