pacer is a nutrition and training system for people who want to hit a protein floor, stay in a calorie target, respect an eating window, and train — without the app becoming a second job. It pairs a member app with a coach app, and the privacy model is the point: the member's log lives in their own CloudKit private database, and a coach only ever sees the one snapshot the member opts to share. Coach seat billing runs in a SvelteKit + Supabase + Stripe web layer, alongside a live web app so anyone can pace their day in a browser today. It is deliberately built for the GLP-1 moment — when appetite drops, protein has to be defended, so the app raises the protein floor to at least 2.0 g/kg the instant a member marks themselves on a GLP-1.
The challenge
Most tracking apps confuse logging with insight. They ask for a lot, give back a wall of numbers, and make the daily ritual feel like data entry. The real problem was attention: the user needs to know, in one look, whether today is on track, and to fix it without thinking. And a nutrition day is not one thing — it is macros, an eating window, training, supplements and a GLP-1 schedule — usually scattered across four or five separate tools that never agree on a verdict, a colour or a dark mode.
- The number you came for is buried under tabs and forms
- Logging a meal takes too many steps to ever become a daily habit
- Progress is shown as raw data, not as an answer to 'am I on track?'
- Nutrition, fasting, training, supplements and GLP-1 live in separate apps
- Dark mode is an afterthought, so the app is harsh at night
- Coaching tools are bolted on, with their own inconsistent UI — and they quietly hand the coach a live window into everything
Discovery & research
pacer started from a familiar failure mode — trackers that bury the one number you came for and turn logging into data entry. Discovery was about what makes a daily ritual stick, what a glanceable 'am I on track?' answer actually needs, how to fold nutrition, fasting, training, supplements and coaching into one system without the bloat, and — for the GLP-1 era — how to keep the member's data theirs while still letting a coach help.
Logging dies the moment it feels like data entry
Most trackers ask for too much per meal, so the habit never forms. The bar I set was a daily ritual you can complete in roughly two taps, which meant designing logging as fast search-and-confirm, one-tap quick-adds and a barcode scan — not a form, and deliberately not a photo-macro guess that would trade a believable number for a magic one.
EvidenceBuilt as a search-or-quick-add flow on the Today dashboard, with a barcode path into Open Food Facts; the only photo a meal carries is an optional downscaled thumbnail attached on save, never a source of macros.
People want a verdict, not a number
'96 g protein' makes the user do the maths. The same figure as a coloured ring, a '44 g to go', or a green-to-red calorie-balance card answers the question they actually have — am I on track right now? So every number is rendered as a judgement, and the judgement is a five-state scale (under-eating, healthy deficit, maintenance, slightly over, over) rather than a naive good/bad, because under-eating is a failure too.
EvidenceThe Today screen leads with the protein ring and a state-coloured calorie-balance card; five verdict states, each a token with paired light/dark values and a darkened text variant, all held above WCAG AA by an automated contrast suite in both themes.
The day is split across four or five apps
Nutrition, fasting, training, supplements and a GLP-1 schedule usually live in separate tools that never share a verdict or a theme. Discovery scoped one system that carries all of it, so the design problem became density-without-clutter rather than feature breadth — one Liquid Glass vocabulary applied to every domain.
EvidenceFasting window, training plan, supplements and a GLP-1 dosing schedule all live in the one member app, assembled from the same component library and the same tokens.
Food numbers have to be both fast and trustworthy
A tracker is only as good as its food data — the 'verdict' colour is meaningless if the grams behind it are guessed. So search rests on a credible, comprehensive source, and the barcode path resolves to a separate open database, with each item tagged by provenance so the app always knows where a number came from.
EvidenceSearch backed by USDA FoodData Central; barcode lookups resolve against Open Food Facts; every food item carries a source tag (bundled / USDA / Open Food Facts).
The GLP-1 era changes the nutrition brief
On a GLP-1, appetite falls and the risk shifts to losing muscle inside the deficit — so protein has to be actively defended, not just tracked. I designed the targets engine to lift the protein floor to at least 2.0 g/kg the moment a member marks themselves on a GLP-1, regardless of their goal, so the number the ring is chasing is already correct for their situation.
EvidenceA GLP-1 schedule in the member app, and a targets engine that clamps the protein floor to a minimum of 2.0 g/kg of bodyweight while a GLP-1 is active.
Coaching is usually bolted on — and usually over-shares
Most apps treat the coach side as a separate, inconsistent product, and quietly give the coach a live window into everything the member does. pacer models coach and member as one design language but keeps the data member-owned: the log lives in the member's own CloudKit, and the coach receives only the one snapshot the member opts to share. On that shared record each side is a strict single-writer — the coach writes back only to reserved coach-owned keys (billing, bookings, invoices today; assigned plan and note staged next), never the member's own fields, so nothing the member logs can ever be overwritten.
EvidenceA dedicated pacer coach app; member-owned CloudKit data published as one opt-in Codable snapshot; a field-scoped no-clobber merge on the shared record; and coach seat billing plus a studio roster in the SvelteKit + Supabase + Stripe web layer — all under one design language.
How I approached it
I built pacer the way you build a system, not a screen. First a token layer: a warm, semantic colour set with paired light and dark values, and on top of it a five-state verdict scale that drives the calorie-balance card. Then a component vocabulary — the Liquid Glass card, the protein ring, the metric tile, the quick-add — so every screen is assembled from the same parts and flips to a fully designed dark mode for free. The food numbers sit on real data (USDA FoodData Central for search, Open Food Facts behind the barcode) so a verdict colour can actually mean something. And the whole thing is wrapped in a privacy-first data model where the member owns their log and shares exactly one snapshot.
Defined semantic colour tokens — a warm palette, paired light + dark, plus a five-state verdict scale for the calorie-balance card
Built a Liquid Glass surface and a small component library on top of it — protein ring, metric tile, quick-add
Designed the Today dashboard around one hero: the protein ring, with a state-coloured verdict card beneath it
Reduced logging to fast search-and-confirm, one-tap quick-adds and a barcode scan — never a form
Sourced trustworthy food data (USDA FoodData Central + Open Food Facts) so the verdict colour rests on real numbers
Modelled a privacy-first data layer: member-owned CloudKit, one opt-in snapshot to the coach, seat billing in a SvelteKit + Supabase + Stripe web layer
Trade-offs
The hard part was density without clutter. A real nutrition day has a lot in it — macros, an eating window, training, supplements, a GLP-1 schedule, coaching — and the screen had to carry all of it and still feel calm enough to read in a queue. Underneath, the privacy model had to let a coach be genuinely useful without ever giving them a live window into the member's raw log.
- Carrying a real nutrition day's complexity without a cluttered screen
- Keeping one consistent Liquid Glass surface legible over a warm background
- Making dark mode genuinely first-class, not a tint — guarded by an automated contrast suite
- Unifying member and coach experiences under one language while keeping the data member-owned
- Letting the coach write back without ever overwriting the member's own fields — a field-scoped, no-clobber merge on a shared record
Final direction
The result is a single, glanceable system across surfaces. The Today screen leads with the protein ring and a state-coloured calorie-balance card; logging is fast search-and-confirm, one-tap quick-adds and a barcode scan — no forms, no photo-guessing. Trends, schedule, billing, the coach app and the web app all speak the same Liquid Glass language, and because everything is token-bound, every surface flips to a fully designed dark mode in one switch. Underneath sits the real design contribution: the member's data stays in their own CloudKit private database (SwiftData locally, roughly eighteen @Model types under CloudKit-safe conventions), and only a single opt-in snapshot — one Codable value, pushed on change over a coalesced CloudKit write — ever reaches the coach. On that shared record, member and coach are strict single-writers: each writes only its own reserved keys, never the other's fields, so a coach's write-back can never clobber the member's log (a field-scoped no-clobber merge; the shipped write-back path today is the coach-owned billing, booking and invoice keys, with the assigned-plan-and-note loop staged as the next phase). Coach seat billing and the studio roster run in the SvelteKit + Supabase + Stripe web layer, with entitlement tiers for solo freelancers and multi-coach studios.
Outcomes
pacer is a real system, not a flat mock-up. The web app is live at app.pacerfitness.com — anyone can pace their day in a browser today — while the two native apps (member and coach) are in TestFlight, built and running, with onboarding, a USDA-backed food database with barcode lookup, fasting, training, supplements, a GLP-1 schedule, and the CloudKit + opt-in-snapshot privacy model. The design contribution is the architecture underneath: member-owned data by default, one deliberate share to the coach, a strict single-writer merge on the shared record, seat billing in the web layer, and a token-first system where coherence and a genuinely first-class dark mode are structural — computed and contrast-tested — across iOS and web.
One system, every screen
Every number should also be a verdict.
A tracker is not really about tracking. It is about answering one question — 'am I on track right now?' — fast enough that the user keeps coming back. Every decision in pacer, from the protein ring to the five-state verdict scale to the single opt-in snapshot, exists to make that answer instant and that trust unbreakable.