AI-Powered Hormonal Health Platform Built in 8 Weeks

femmflo · Healthcare · 2025 · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Women's hormonal health AI platform

FemmFlo wanted to launch a personalized hormonal-health assistant quickly for underserved women while handling sensitive medical data, culturally localized advice, lab results, clinical guidelines, and healthcare hallucination risk.

Constraints:

• health advice must be clinically checked before reaching users
• personal health and lab data require secure user separation
• the initial MVP had an aggressive eight-week timeline
• startup economics required low upfront infrastructure cost
• localized recommendations must avoid generic Western-centric advice
• model choice must balance medical knowledge, latency, and cost

Architecture

FemmFlo and Millio AI built Gabby as an AWS Bedrock agent behind an API Gateway and interface Lambda. Open Web UI on ECS Fargate provided the testing/chat interface, while EFS and RDS supported uploads and conversation history. The interface Lambda retrieves onboarding context from DynamoDB, sends traces to Langfuse, and invokes the Bedrock agent with prompt, tool, and guardrail configuration. The agent can call a Lambda tool that retrieves structured lab results from S3; uploaded lab PDFs are first converted through a structured extraction process. A science officer validates responses in the controlled testing workspace before logic is promoted to the mobile app.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  open-web-ui["open-web-ui"] --> api-gateway["api-gateway"]
  open-web-ui --> ecs-fargate["ecs-fargate"]
  open-web-ui --> elastic-file-storage["elastic-file-storage"]
  open-web-ui --> rds-conversation-store["rds-conversation-store"]
  api-gateway --> interface-lambda["interface-lambda"]
  interface-lambda --> dynamodb-onboarding-store["dynamodb-onboarding-store"]
  interface-lambda --> langfuse-observability["langfuse-observability"]
  interface-lambda --> bedrock-agent["bedrock-agent"]
  bedrock-agent --> bedrock-guardrails["bedrock-guardrails"]
  bedrock-agent --> lab-results-tool["lab-results-tool"]
  lab-results-tool --> s3-lab-results-store["s3-lab-results-store"]
  structured-lab-extraction["structured-lab-extraction"] --> s3-lab-results-store
  s3-lab-results-store --> lab-results-tool
  bedrock-agent --> science-officer-review["science-officer-review"]
  science-officer-review --> mobile-app["mobile-app"]
  langfuse-observability --> evaluation-framework["evaluation-framework"]
  evaluation-framework --> bedrock-agent

Components

Data flow

A user onboards with geographic, health, mental-health, and personalization context, then chats with Gabby or uploads lab results. The UI calls API Gateway, which routes to an interface Lambda. The Lambda fetches onboarding context from DynamoDB, records traces in Langfuse, and invokes the Bedrock agent. The agent receives its objective, prompt configuration, tools, and Bedrock guardrails; when lab context is needed, it calls a Lambda tool to retrieve structured S3 lab results produced from uploaded PDFs. In the testing workflow, Gabby's answer is checked against user data and clinical guidelines by the science officer before the same logic is promoted to the mobile app.

Why this architecture

The architecture favors managed AWS services and a simple retrieval design because the team needed a secure healthcare MVP in eight weeks. Bedrock Agent centralizes agent configuration, tools, and guardrails; API Gateway and Lambda keep integration lightweight; DynamoDB and S3 are enough because the first knowledge base is small and structured; Langfuse and the evaluation framework make behavior inspectable; and science-officer review protects medical accuracy before release.

Models used: AWS Bedrock agent · Claude 3.5 Sonnet · large language model used as evaluator

Scale

• FemmFlo built the AI MVP in eight weeks.
  “how AWS's technology helps take Tal's idea and turn it into the first LLM powered platform for hormonal tracking, diagnostics, mental health, and personal care all in eight weeks.”transcript, stated
• The platform reached beta users, lab integrations, and partnerships by the time of the talk.
  “She has bootstrapped Fimflow to a full MVP with beta users, lab integrations, and partnerships.”transcript, stated
• The cited women's-health problem includes a seven-year diagnostic wait affecting 70% of women in public health.
  “70% of the women in public health wait for seven years to get an accurate hormonal related diagnosis.”transcript, stated
• The presentation cites 30% symptom prevalence, 82% willingness to pay, and $18,000 lifetime out-of-pocket spend.
  “30% of women report symptoms like fatigue, pain, and mood changes without effective tracking or care. And most importantly, 82% of women say that they will pay”transcript, stated

  “an average woman spent $18,000 over her lifetime of outofpocket care just chasing answers.”transcript, stated
• The business case frames a $12 billion market and an $800 million underserved launch market.
  “This is a $12 billion market of women with hormone and mental health needs. Vimflow is starting with an $800 million launch market”transcript, stated
• Daily check-ins are designed to take under a minute.
  “It's broad enough to capture her lift experience, but it's also light enough that it can be done under a minute”transcript, stated
• Millio describes the repeatable AI MVP process as roughly $10,000 with a four-person team.
  “we usually do this for around $10,000 um with a team of four people. So, a product owner, AI engineer, cloud engineer, and a software engineer.”transcript, stated

Alternatives considered (roads not taken)

Treat AI as an add-on feature

Rejected because: FemmFlo put Gabby at the center so data could be structured once and reused across onboarding, check-ins, diagnostics, and care guidance.

Use a vector store for retrieval

Rejected because: The initial knowledge base was small, structured, and needed as whole records, so vector search would have added complexity without benefit.

Choose the largest model for maximum health-domain knowledge

Rejected because: The team evaluated multiple models and picked the smallest model that met knowledge, latency, and cost requirements.

Build custom infrastructure before validating the MVP

Rejected because: Managed services, serverless components, and Open Web UI let the team focus on differentiated healthcare logic during the eight-week window.

Patterns

tool-use-orchestration (architecture)

The Bedrock agent is configured with tool access and an interface Lambda that supplies onboarding context, observability, and structured lab retrieval.

guardrails-io-filtering (safety)

Bedrock guardrails refuse inappropriate topics, while the test workspace lets the science officer tune prompts and guardrails before production promotion.

human-in-the-loop-gate (control)

A science officer validates Gabby's responses and the clinical guideline alignment before the same logic reaches app users.

eval-driven-development (process)

The eight-week process starts with success definitions and evaluation datasets, then iterates against metrics before production readiness and red-team testing.

observability-tracing (operations)

Langfuse traces expose the question, agent reasoning, tool use, and path to the final answer for evaluation and debugging.

structured-output-contract (data)

Uploaded lab PDFs are converted into structured lab results in S3 so the agent retrieves clean fields rather than reasoning over arbitrary documents.

model-routing (model selection)

The team ran the evaluation framework across candidate models and selected Claude 3.5 Sonnet as the smallest model satisfying quality, latency, and cost criteria.

privacy-preserving-processing (safety)

The system emphasizes user separation and no cross-talk for sensitive medical lab data.

cost-aware-routing (operations)

The architecture uses serverless AWS components and smallest-sufficient model selection to control infrastructure and conversation costs.

Tradeoffs

Make Gabby the core platform interface

Chose AI-first architecture over AI as an add-on to a conventional health app.

Rationale: Putting Gabby at the center let the team structure data once and reuse it across onboarding, check-ins, lab results, and care-plan interactions.

Skip vector retrieval in the MVP

Chose structured DynamoDB and S3 retrieval over a vector-store RAG architecture.

Rationale: The needed records were small, structured, and usually retrieved whole, so vector search would have slowed the MVP without adding value.

Choose the smallest model that met evaluation criteria

Chose Claude 3.5 Sonnet at development time over larger models by default.

Rationale: The selected model had enough built-in health knowledge while keeping latency and cost acceptable.

Use managed and open-source building blocks for speed

Chose Open Web UI, API Gateway, Lambda, ECS Fargate, RDS, EFS, S3, DynamoDB, and Bedrock over custom app and infrastructure from scratch.

Rationale: Managed services absorbed undifferentiated infrastructure and helped the small team launch quickly on a pay-as-you-grow basis.

Gotchas (what bit them)

Healthcare hallucination risk requires a real validation path, not just a polished chat UI.

Root cause: Gabby provides medical-adjacent advice over sensitive lab and symptom data, so incorrect responses could be harmful.

Resolution: The team built a controlled Open Web UI testing workspace where the science officer validates responses, prompts, guardrails, user-data alignment, and clinical guidelines before app promotion.

A default RAG/vector-store design would have added unnecessary complexity.

Root cause: The first-version knowledge base was small, structured, and usually needed as complete records rather than retrieved snippets.

Resolution: The team used DynamoDB onboarding retrieval and an S3 lab-results tool instead of a vector store.

Generic health recommendations can fail culturally and economically.

Root cause: Western-centric datasets can suggest advice that is unavailable or unaffordable for underrepresented users in local contexts.

Resolution: FemmFlo stores localized and user-specific data so Bedrock can personalize recommendations to the user's geography and realities.

The smallest-sufficient model choice is time-sensitive.

Root cause: The model market changes quickly, so a model selected during development may not remain the best quality-latency-cost point.

Resolution: The speaker explicitly notes rerunning the evaluation as newer models arrive.

Evaluation

Millio's process defines success up front, builds an evaluation dataset with subject-matter experts, combines human and LLM-based evaluation, uses red-team adversarial questions, and monitors response latency, conversation cost, traces, failures, and component interactions.

Metrics: answer quality across health-question categories · lab-result question accuracy · user-profile-specific answer quality · adversarial/refusal behavior · response latency · conversation cost · trace-level tool and reasoning behavior

Outcomes

• FemmFlo reached a full AI MVP with beta users, lab integrations, and partnerships in eight weeks.
• The system lets users chat with Gabby, upload lab panels, receive plain-language explanations, and get context-aware lifestyle recommendations.
• The testing workflow supports prompt and guardrail iteration before mobile app promotion.
• The same architecture is positioned for later B2B, insurer, employer, and public-health deployments.

The talk cites an eight-week build, beta users and real data, a $12 billion market with an $800 million launch segment, under-a-minute check-ins, a roughly $10,000/four-person MVP recipe, and a planned $75,000 SAFE raise.