Case Study — 02
Designing AI nutrition tracking that clinicians and high-risk patients can actually trust
A pregnancy-first nutrition app architected for clinical populations — with the accuracy standards, privacy model, and trust architecture that implies. The product photos a meal, identifies it with Claude vision, fires condition-specific safety flags, and returns a structured log entry for user confirmation.
Context
The market that no nutrition app actually built for
Nutrition tracking apps are built for general dieters. They show macros. They do not understand that folate and DHA matter more than calories during pregnancy, that potassium is a ceiling nutrient in CKD, or that glycemic load means something categorically different to a diabetic than to someone cutting for summer.
3.6 million pregnancies occur in the United States each year. 37 million Americans have diabetes. 120 million have hypertension. These are not edge cases — they are the majority of adults who most need nutrition precision. Yet every major tracker (MyFitnessPal, Cronometer, Noom, ZOE) was designed for the motivated-but-healthy dieter. Clinical populations are either excluded or stripped of clinical context in favor of general-diet monetization.
No AI-native nutrition tracker existed that was built for clinical-adjacent use — with the precision standards, privacy posture, and trust architecture that implies. That was the gap.
Problem
It wasn't that nutrition apps are bad. They were designed for the wrong user.
That user-choice baked in assumptions that make the product wrong for clinical populations at every layer: what nutrients to surface, what counts as a dangerous food, how to share data with a care team, how to handle the fact that a serving of tuna means something categorically different in the second trimester than in a general diet.
Clinical populations don't need a feature request on top of a fitness app. They need a different trust model from the ground up. And underneath that was a harder problem:
"In a fitness app, a 30% calorie overestimate is noise. In a pregnancy app shared with an OB, it's a liability. The job was defining what clinical-grade accuracy means — then building the eval methodology to prove it."
ZOE's published validation study shows AI models score 0.07 out of 1.0 on soups and 0.13 out of 1.0 on plant milks. The PM question wasn't "should we use AI?" — it was how to define what clinical-grade accuracy means for this context, and then build the methodology to verify we actually hit it.
Approach
Six decisions that determined everything else
Define the user precisely before designing anything
Primary user: a pregnant person in the US who wants confidence she is meeting key pregnancy nutrient targets (folate, iron, calcium, DHA, vitamin D, choline, iodine), avoiding pregnancy food risks, and able to share a coherent summary with her OB. Explicit non-users for v1: general dieters, bodybuilders, eating-disorder recovery, and clinicians as the primary app user (they consume the shared report only). This precision resolved ambiguous decisions cleanly throughout the build — every feature question had a direct answer.
Map the AI failure modes first, then design around them
Before writing a line of product code, ZOE's published accuracy research was used to identify where AI food logging fails hardest: soups, stews, plant milks, nut butters, sauce-based dishes. Per-category accuracy gates were set before any code was written. The 250-photo golden evaluation set — stratified with ~40 safety-risk photos and ~30 weak-category photos — became the gate for every prompt change and model upgrade.
Design the confirmation UX as the trust mechanism
No AI decision writes to the log without the user reviewing it. Low-confidence items render with a distinct visual treatment and a "tap to verify" affordance. Safety flags (unpasteurized dairy, high-mercury fish, raw seafood, excess caffeine) surface at the top of the confirmation screen with blocking or dismissable treatments depending on severity. The user cannot tap Log until every flag is acknowledged or resolved. After two weeks of use, the model incorporates per-user portion history ("your typical oatmeal is ~65g based on 12 prior logs") — building trust by showing the system is learning from the user, not just guessing.
Design principle
A silent wrong answer is worse than a friction-generating right one. For structurally ambiguous categories, the model returns a clarification prompt and a mandatory input — not a slider. A slider implies the model's estimate is a reasonable starting point. A mandatory input signals the model is genuinely unsure.
Build a clinician-shareable report with a privacy architecture to match
The clinician report is the feature that separates this from every other nutrition tracker. An OB or dietitian receives a nutrient trend summary — daily averages against trimester-adjusted targets, safety flag history, supplement breakdown, gestational weight-gain chart — without requiring a login or installing anything. The privacy architecture: snapshot-frozen payloads (later food log edits do not retroactively mutate what the clinician saw), time-limited revocable tokens with default 7-day expiry, and per-access logging surfaced in-app ("Dr. Smith's browser viewed this report 3 times"). The report presents data without editorializing — no risk scores, no recommendations. Data presentation, not medical advice.
Design freemium to prove clinical value first, gate depth not relevance
The first version paywalled all pregnancy-specific micronutrients — folate, iron, DHA. This was wrong. If those are paywalled, the free tier proves nothing except that the app understands macros, which every competitor already does. The revised design keeps three nutrients free: the three a pregnant user is most actively trying to track.
- ✓Folate, iron, DHA tracking with trimester-adjusted targets
- ✓All pregnancy safety flags (unpasteurized dairy, mercury, etc.)
- ✓Accurate daily totals including supplement adjustment
- ✓7 days of log history
Proves pregnancy-specificity on day one. The product's core value is not paywalled.
- ✓Full micronutrient panel (calcium, choline, iodine, B12, magnesium, vitamin A ceiling)
- ✓Clinician report + shareable link
- ✓Unlimited log history
- ✓Condition-aware meal planner
Additive depth, not a punitive gate on relevance.
Architect for extensibility before the first public release
The nutrient target layer was built as condition-parameterized from day one. The pregnancy_rdas reference table is not a pregnancy table — it is a condition_rdas table that happens to be seeded with pregnancy data first. Each row has a stage and an adjustments field for diet-pattern modifiers (vegans need ~40% more iron due to non-heme absorption; multiple pregnancies have higher DHA targets). The same schema serves CKD potassium ceilings, diabetic glycemic targets, and hypertension sodium limits — with different condition values, not different tables. The multi-condition framework was shipped during the closed beta period, not Phase 4 as originally planned.
Outcome
87% confirmation rate. Every safety risk caught. Architecture ready for four conditions.
26 closed beta users recruited through pregnancy communities and one OB/RD partner. 87% of meals were confirmed without manual ingredient edits within the first two weeks — exceeding the ≥85% design target set at the start of the project.
The evaluation methodology: a 250-photo golden test set assembled before the beta began, with ground-truth ingredients, portions, and nutrients for every image. The set was explicitly stratified: ~40 photos of pregnancy safety risks, ~30 photos in known-weak categories, and ~180 photos across the general distribution. Per-category accuracy gates were set before any code was written — so the eval set functioned as an objective gate on every prompt change, not a post-hoc rationalization.
All 40 pregnancy safety-risk photos in the evaluation set triggered the correct flag type. No safety risk passed through the model undetected during the beta period.
The multi-condition framework, pantry management, and condition-aware meal planning all shipped before the public launch. The backend architecture that pregnancy users are using today is the same one that will serve CKD, diabetes, and hypertension users without a rebuild. The HIPAA-ready data posture, versioned clinical reference tables, and snapshot-frozen report tokens are the same infrastructure a regulated DTx product would need.
On competitive position: the free tier offers folate, iron, and DHA tracking with trimester-adjusted targets — the three nutrients a pregnant user is actively searching for. No competing free tier in the market offers this. ZOE's free tier shows macros and excludes pregnancy entirely.
What I Learned
Two things about clinical products that are not obvious in fitness apps
Trust is an architecture decision, not a copy decision. You can write all the disclaimers you want. What actually builds trust in a clinical-adjacent product is structural: the AI never writes to the record without the user confirming it, the report payload is frozen at generation time so the clinician sees exactly what existed then, and the audit log tells the user when their report was accessed and by whom. These are not UX decisions. They are architecture decisions, and they need to be made at the beginning — not added as an afterthought when a clinician asks uncomfortable questions.
Paywalling accuracy is fatal in clinical freemium. A user who can't trust the free tier won't pay for the paid one. In practice, this meant keeping safety flags and the three core pregnancy nutrients free even though they are the product's clearest demonstration of value. The right paywall gates depth of data and clinical workflow features — not the clinical relevance that makes the product worth opening in the first place.
Key Decisions
Eight calls that defined the product
| Decision | What was chosen | Why |
|---|---|---|
| Primary persona | Pregnant user, not general dieter | Enables clinical specificity; general-diet app is a different product |
| AI architecture | Claude vision → user confirm → USDA fallback | Confirm-before-save + cited fallback enables clinician trust |
| Safety paywall | Never | Safety gap destroys trust faster than any conversion lift recovers it |
| Free-tier nutrients | Folate, iron, DHA only | Prove pregnancy-specificity in the free tier; gate depth not relevance |
| Nutrient target schema | Condition-parameterized, not pregnancy-specific | Multi-condition extensibility without schema rebuild |
| Report payload | Snapshot-frozen at generation time | Clinical record integrity — later edits cannot alter what the clinician saw |
| Regulatory posture | Wellness + optional clinician share (HIPAA-ready) | Avoids FDA medical device pathway while preserving upgrade option |
| Eval methodology | Stratified 250-photo golden set, gates set before code | Objective gate on every prompt change, not post-hoc rationalization |