Case study / 02 / A connected personal health product
A private iPhone-first app that connects food scanning, nutrition, training, recovery, skin, and journaling. I built the product around a simple idea: useful guidance starts with records you can trust and correct.
Explore a fictional day. No sign-in or personal records.
Interested in ingredient review, food logging, or a more connected daily journal? Tell me which part would be useful to you.
Private build. Full app access and pricing are not available yet.
22 seconds / Ingredient review
Personal preferences and general evidence answer different questions. Watch the review keep them separate, surface missing sources, and show the explanation behind a finding.
Actual web-interface captures with fictional ingredients and references. Generated supporting imagery and narration; original music. Early private build.
An ingredient flag should come with an explanation. Personal Trainer keeps your preferences separate from general evidence. If a source is missing, the review says so. Read the finding. Check the reason. This is an early private build. See the walkthrough at the link.
Actual responsive web interface
Food, movement, recovery, and reflection share a daily timeline. Four primary destinations keep the product learnable even as its capabilities grow.
The daily-path and journal interaction language grew out of my earlier Treadway project. Personal Trainer extends that work into a native iPhone client and a structured nutrition and evidence system.
Captured from the running web app’s read-only preview, September 2026. Synthetic records only; these are not native-iPhone screenshots or private account data.
Review before you record
A saved meal still needs a date, a meal, and the amount actually eaten. The review puts those choices beside calories, protein, carbs, and fat—even for a fractional portion.
Before finishing a workout, the review shows completed sets and whole active minutes. It explains the one-minute recording minimum and keeps paused breaks out of the duration.
Actual development component captures with fictional records · October 6, 2026. These web improvements are separate from the public interactive preview. Full-app customer accounts and physical-device release checks remain unfinished.
Discuss a focused interface fix
Native capture / Actual review screen
I checked the complete path from a fictional US nutrition label in the system Photos picker through unmodified on-device Apple Vision to this review. The accepted source stayed linked to the extracted values, printed serving basis, and editable fields.
Recognition left verification off and confirmation disabled. Nothing was logged or saved to an account. Closing the review and explicitly discarding the local draft were checked too.
Actual iOS Simulator capture with fictional label data · October 6, 2026. Source and Simulator evidence only. Camera capture, physical-device behavior, live accounts, general OCR accuracy, and customer launch remain unverified.
Discuss a focused interface fix
8 seconds / A focused native interface repair
The calorie prompt was clipped at enlarged text. This short comparison shows the problem, then the adjusted Calories prompt and unit.
My own development work, October 7, 2026. Separate fictional iOS Simulator stills, edited for comparison—not a continuous workflow. The after view shows Calories only. No live account, physical-device, saved-record, or customer-result claim.
Before: The calorie prompt gets clipped. After: Now the prompt and unit fit. See the work: paxtonraithel.com. Fictional Simulator demo · source candidate.
01 / The product problem
Food scanners, calorie trackers, and journals usually create separate histories. Combining them is useful only if a guessed serving, missing nutrient, or model suggestion cannot quietly become a fact. Personal Trainer makes capture, correction, intake, and interpretation separate steps inside one everyday experience.
02 / My contribution
I defined the connected product, directed implementation and independent AI-assisted audits, shaped the data and evidence contracts, and tested the app on my phone. Real failures—small print, curved labels, incomplete barcodes, and interrupted saves—feed back into regression tests and release decisions.
The everyday workflow
Nutrition and ingredients have separate capture paths. A long ingredient list can be photographed closer without making the nutrition panel fit the same frame. Public barcode matches are references to review—not permission to guess missing macros.
03 / Engineering decisions
A corrected label, a delayed response, an offline save, and an account switch all change what the app is allowed to trust. I designed those boundaries as part of the product, not as cleanup after the demo.
Native Apple Vision reads nutrition labels on-device. Barcode references and separate close-up ingredient captures feed a correction screen; saving a product is distinct from logging the amount eaten. Missing macros stay unknown, not zero.
A deterministic evidence system separates allergy and preference matches from scientific attention flags. It distinguishes hazard from realistic exposure, restrictions from bans, and incomplete evidence from reassurance. Colors and preservatives are not automatically penalized.
Today, Log, Progress, and Journal connect saved meals, macros, workouts, hydration, sleep, skin observations, body measurements, and dietary needs. Paper-journal capture is reviewed before it joins the written record. Ordinary tracking works without a model.
Fast commands use explicit app actions; optional Ollama assistance receives bounded, consented context. A private MCP server supports interactive assistant access. Models do not invent nutrient values, ingredient ratings, or medical conclusions.
Supabase Row Level Security, private image storage, owner-bound queues and replies, idempotent saves, audit history, export, and deletion are treated as connected controls. Administrative usage summaries exclude private photos and journal prose.
Parser fixtures, native tests, API checks, and synthetic multi-owner exercises cover different failure classes. Device observations remain separate from source checks. Generated deep-journal interpretation stays disabled because tested local models did not meet its evaluation bar.
Ingredient analysis
The same ingredient can mean different things depending on route, exposure, jurisdiction, and the person. A warning requirement is not a ban; an association is not proof of causation.
04 / Evidence and honest limits
The implementation includes native capture, structured tracking, privacy controls, local assistance, and deployment tooling. Source and fictional-data checks support the engineering work. A current customer account walkthrough, broader physical-device testing, and a customer pilot remain necessary before opening the full app.
No universal OCR accuracy, clinical validation, end-to-end encryption, completed App Store launch, paid-user traction, or proven market value. Long-label capture, broader device coverage, accessibility, and sustained daily-use evaluation still need real-world evidence.
Deep automatic journal interpretation is deliberately unavailable after failed model qualification. A refusal to overpromise is a product decision too.
Ask me about the architecture