CS-16 // Dossier
Newborn-care companion app
A cross-platform infant-care tracking app built from a folder of flat client mockups — turned into a token-driven design system, then a shipping mobile application with an offline-first logging path, a mascot-driven guidance engine, and multi-caregiver data isolation proven by tests.
Exhibit // CS-16
R-02 · interface redrawn from the live build — zero client pixels
- Client
- R-01SEALED UNDER NDA. SPECIFICS WALK THROUGH LIVE. → BOOK
- Industry
- Consumer app founder · via agency partner
- System
- Newborn-care companion app
- Stack
- Expo · React Native · Supabase · TypeScript · TanStack Query
- Trigger
- A folder of flat mockups, a store deadline, and 3am logging on bad wifi
- Metrics
- System scope
01 // The problem
The client supplied designs as flat images with no measurable values — seven near-identical background creams and five different navigation bars — so no developer could build without guessing. And the core use case is logging a feed at 3am on bad wifi, on a backend with no offline sync, so the offline strategy had to be right before the schema was written.
02 // The system
Redrawn — no client data
The system
03 // The delta
Before and after go-live
Before
- Designs as flat images with seven different creams and five nav bars
- No app, no schema, no offline answer for 3am logging
- Client artwork existing only inside PDFs
- A store deadline with no repo behind it
With the system
- 31 screens live on one token system
- Offline-first logging that survives crashes without double entries
- The client’s actual logo and mascot, extracted at native resolution
- ~390 tests green and milestones tracked in weekly written updates
04 // What got done
6 entries
- B-01Mined the client’s own mockups and PDFs for embedded full-resolution artwork — recovering ~60 native assets including six mascot states, so the logo is the client’s logo, exactly
- B-02Rebuilt 25 screens on shared design tokens — a global change is one edit, not twenty-five — then extended to the screens the mockups never covered
- B-03Built an insert-only offline outbox on client-generated ids with duplicate-ignoring writes, so replaying a queue after a crash cannot double-log a feed
- B-04Split persistence deliberately: a plaintext short-lived queue for pending writes, an encrypted store for the long-lived read cache
- B-05Modelled households and memberships with 27 row-security policies and a dedicated isolation test suite — multi-caregiver privacy proven, not asserted
- B-06Ran the engagement on weekly written updates that separate built from blocked-on-your-accounts, naming store-credential lead times as schedule risks weeks ahead
05 // Outcome
System scope — capability metrics, honestly labeled
- → Scope
route screens across six flows - 0
- → Scope
row-level-security policies, proven by a test suite - 0
- → Scope
client assets recovered from flat mockups - ~0
06 // The result
From the build log
- Core tracking code-complete ahead of the milestone; multi-baby support pulled forward a month
- Crash replay cannot double-log an event — by construction
- A deployed click-through prototype the client could tap before a line of app code existed
Want a system like this one?
Free · 30 min · leave with a rough scope either way