Building Bloom: Cycle-to-Pregnancy Tracking With Rule-Based Insights, Not Diagnostic AI

I shipped Bloom (bloom_tracker) — a Flutter companion for reproductive wellness across four goals:

1. Track cycle
2. Conceive
3. Pregnancy
4. Postpartum

Users don’t live in one mode forever. Confirming pregnancy, recording birth, or returning to cycle tracking mutates Goal in AppState and reshapes Today, insights, and which tools matter.

Logging that matches how people actually track

A DayLog can hold flow, mood, symptoms, water, notes, BBT, cervical mucus, OPK result, intimacy, energy, and pain. Cycle phase is derived (period / follicular / fertile / ovulation / luteal) from cycle length and an ovulation-day estimate — classic calendar math, on-device, no account required.

Fertility-aware fields matter for conceive mode; pregnancy mode leans on kicks, contractions, vitals, and week content instead.

Pregnancy tools that stay concrete

• Due date: last period start + 280 days (standard gestational estimate). Days remaining clamped for UI.
• Kick counter: timestamps per kick; count “today”; clear today’s kicks; playful pop animation on tap — useful as a simple awareness tool, not a clinical NST.
• Contractions: start + duration; contractionIntervalMin averages gaps when ≥2 contractions fall in the last 2 hours. Surfaces timing so a parent can discuss patterns with their care team — the app does not diagnose labor.
• Weight, blood pressure, blood sugar entries with charts.
• Appointments and free-form medical notes (parent-authored).
• Week card: size analogy, length/weight copy, tip from PregnancyContent.

Content module header says it plainly: educational only, not medical advice. Foods to eat/avoid, exercise/sleep/mental tips, warning-sign keys — all translation keys, not hard-coded English.

Insights without an LLM costume

generateInsights() builds BloomInsight cards from:

• today’s energy/pain check-in
• current cycle phase
• opted-in conditions (PCOS, endometriosis, anemia, migraines, thyroid, diabetes, high BP, …)
• pregnancy-specific guidance when goal == pregnancy
• patterns from logged cycles where relevant

It’s a rule engine, same family as KegalFlow’s Adaptive Recovery and iRun’s grounded coach: named situations → copy. No model invents a diagnosis. Condition cards are supportive education keyed off what the user already said about themselves.

That distinction matters for App Review and for trust.

Continuity into postpartum

Birth confirmation moves goal to postpartum, seeds recovery-oriented content, and keeps the same local store. One app lifespan instead of three installs.

Persistence is SharedPreferences + JSON lists (kicks, weights, contractions, appointments, …). Provider/ChangeNotifier for app state. IAP, ads, remote config, notifications for reminders — the usual store shell around a serious domain model.

What I’d still harden

Keep disclaimers adjacent to contractions, warning signs, and condition insights. Export/delete for sensitive reproductive data should be obvious. If “average cycle” informs predictions, show confidence / data sparsity the way Race Twin withholds thin evidence. Avoid any store screenshot that looks like a labor-alert medical device.

Bet: reproductive apps earn trust when math and rules are visible — and when “AI” isn’t used to launder certainty.

If you’re building pregnancy or cycle products: ship kick/contraction utilities as logs with context, and keep insight engines deterministic.