The problem
Fasting research wasn't built for a female body.
Most intermittent-fasting and fitness research was conducted on men, then applied to everyone. But a woman's metabolism, insulin sensitivity, and stress tolerance shift measurably across the menstrual cycle — so a single fasting protocol fits some weeks and works against the body in others. Phasely adapts fasting windows and movement guidance to five cycle phases — Reset, Build, Peak, Sustain, Soften — instead of treating every day as interchangeable.
What I built
Six systems, one phase-aware core.
-
Phase-aware fasting windows
Fasting length and eating window recalculate daily from cycle day and predicted phase — tightening during Reset and Soften, opening up during Build and Peak.
-
Hormone-curve visualization
Estrogen, progesterone, and testosterone rendered as a continuous curve across the cycle, with the current day marked, so the reasoning behind a recommendation is visible, not just asserted.
-
AI coach with cited sources
A conversational coach answers questions about fasting, training, and symptoms, citing the specific framework or study behind each answer rather than generating unattributed advice.
-
Meal-photo analysis
A photo of a meal returns an itemized food breakdown and an inflammation indicator, scored against the user's current cycle phase.
-
HealthKit cycle sync
Cycle data syncs from Apple Health, so users who already log periods elsewhere don't have to re-enter history.
-
Active-fast timer
Tracks the current fast against the day's suggested window, with last-meal and next-meal times shown against real time rather than a bare countdown.
Screens
Today — phase & fasting window
AI coach — cited answers
Cycle calendar
Meal insight — vision analysis
Phase detail
The engineering
Under the hood
Phasely is an Expo (SDK 54) / React Native app written in TypeScript, with Zustand for state. The backend is Supabase — Postgres, Edge Functions, and pgvector for retrieval. The marketing site is Astro, deployed on Vercel.
Request flow
Every answer is generated from retrieved passages, not the model's own memory of physiology — the pipeline is designed so the model can't skip the citation step.
-
Knowledge base
About 160 chunks, distilled from six expert frameworks and fifteen peer-reviewed studies. Each chunk is a semantic unit — one claim or protocol, not an arbitrary character split — sized so a single retrieved passage reads coherently on its own. Every chunk carries source metadata, which is what makes citation possible downstream.
-
Retrieval
A user question is embedded into the same 1536-dimension space and matched against the store by cosine similarity. Only the top-k matches — not the whole knowledge base — are passed to the model as context, which keeps the prompt small and the signal high.
-
Grounding
Claude is instructed to answer only from the retrieved passages. When the store doesn't contain a confident answer, the coach says so instead of inventing physiology. That constraint is deliberate — it's the difference between a coach and a plausible-sounding guess.
-
Citation
Every answer traces back to the specific framework or study it drew from, because each retrieved chunk carries its source forward into the response. Nothing is generated as free-floating advice.
-
HealthKit
Cycle data touches Apple's most sensitive data class — health records — so the integration is read-where-possible: Phasely reads existing cycle logs from Apple Health rather than requesting write access it doesn't need, and syncing requires explicit consent. Phase predictions are computed locally from that data, not derived from anything shared off-device. This sensitivity is exactly what drew App Review's attention to the Health integration — more on that below.
-
Vision
Meal photos go through Claude's vision capability, which returns a structured food breakdown and an inflammation score weighted against the user's current cycle phase — the same ingredients read differently in Reset than in Peak.
-
Cost control
The free tier is capped at ten lifetime coach queries, enforced server-side by a Postgres rate-limit function — not a client-side check that a modified request could skip.
Decisions & tradeoffs
Why, not just what.
-
Claude Haiku over a larger model
A chat coach lives or dies on latency and per-query cost at scale. Haiku answers fast and cheap, and for grounded synthesis over a small set of retrieved passages, a larger model didn't meaningfully improve output quality — retrieval is doing more of the accuracy work than model size.
-
Server-side rate limiting over client-side
A client-side query cap is a suggestion, not a limit — a modified request bypasses it trivially. The ten-query free cap is enforced inside a Postgres function on the backend, so it holds regardless of what the client does.
-
Retrieval over fine-tuning
The knowledge base changes as frameworks and studies get added or revised, and every answer needs to cite its source. Fine-tuning bakes knowledge into weights with no attribution and needs retraining to update; retrieval keeps answers current and traceable without touching the model.
Shipping it
The App Store review
Navigating App Review is where a lot of solo builds stall — not because the code is wrong, but because the guidelines stay underspecified until a reviewer applies them to your app. I treated each response as a spec to satisfy, not an obstacle to argue with.
-
2.5.1 — HealthKit No rebuild
Review couldn't locate the Health integration in the UI. Resolved by replying with an exact walkthrough and a screen recording.
-
5.1.2(i) — Third-party AI data sharing One rebuild
Apple requires explicit in-app consent before user data is sent to an AI provider — a privacy policy alone doesn't satisfy this. Added a dedicated consent screen gating the coach, naming exactly what data is sent and to whom (Anthropic), with required opt-in.
-
2.1 — Information needed No rebuild
Review asked for the exact steps to locate the disclosures. Answered with a precise path through onboarding to the consent screen.
Approved
Three guideline interactions. One code change. Shipping is a skill, not an afterthought.
What it taught me
Building Phasely meant learning production AI-privacy compliance under an actual reviewer, not a checklist; designing a RAG pipeline end to end, from chunking through citation; and relearning that the distance between working on a simulator and live on the App Store is real engineering, not a formality at the end of it.