Development of fuchcia: A Privacy-First Health App

A comprehensive women’s health app from wellness to community turned into a specific app for migrant women (meaning women who've left their native country for another) living with endometriosis. Before building, I ran a structured discovery sprint to test whether the problem was real, specific, and worth building for, and to decide whether to proceed at all.

Distributed to target users to surface needs and frustrations in the problem space.Identified recurring themes to define the problem clearly before touching any design.Built initial prototype to test concept resonance before committing to development.Iterate, pursue partnerships, or kill the idea, based on evidence, not assumptions.

Women on different continents do not experience life in the same way, nor do they approach their mental and gynaecological health in the same way. The problem is unequal access to care and to a supportive community, which could benefit those with chronic illnesses. A specific app for underrepresented communities could connect them with more privileged groups and improve their well-being and co-education.

Early responses confirmed the emotional and financial weight of the problem but also revealed the risk: the scope is broad and target users’ needs vary widely. The prototype was designed to test one specific slice of the problem not the whole vision at once.

I resisted the urge to design a full app immediately. Instead, I built the minimum prototype needed to get a clear yes or no on the core hypothesis. That decision saved weeks and kept the feedback focused and usable.

Status, Decision

✓ Keep

I’m not killing the idea. The research confirmed the pain is real, emotionally and financially. What’s broken is the scope, not the insight. Abandoning the idea at this stage would be the wrong call.

↗ Rethink

I’m narrowing the problem and the target. No more comprehensive solution. My original problem statement covered chronic illness, mental health, gynaecological health, geographic inequality, and community access at once. That’s five products in one. I’m picking the one pain that is the most frequent, most urgent, and most underserved: one persona, one problem, one context. And I’ll define a falsifiable niche hypothesis before I talk to anyone.

↗ Rethink

I’m going deeper on market research but with a hard deadline. I need a clearer picture of the competitive landscape and adjacent products before I go back to users. But I’m time-boxing this to two weeks: map competitors, estimate market size, identify what existing solutions don’t do. After that, I stop desk research and start talking to people.

↗ Rethink

I’m dropping LinkedIn forms and going where my users actually are. LinkedIn didn’t fail because of the platform. It failed because a form link asks strangers to do work for me. I’m moving to spaces where women already talk about these issues: Reddit communities (r/PCOS, r/Endo, r/WomensHealth), Facebook groups, Discord servers, WhatsApp circles, and patient advocacy organisations. I’ll listen first, then ask for a 20-minute conversation.

✓ Keep

I’m switching from forms to real interviews. 50 to 100 of them. Forms gave me 5 responses and no real signal. Conversations build trust, surface nuance, and turn participants into early advocates. I’m committing to 5 interviews per week, which gets me to 50 in 10 weeks and fits within my June deadline. At interview 20, I’ll pause to synthesise what I’ve heard and adjust the niche hypothesis if the signal points somewhere unexpected.

✓ Keep

I’m rebuilding the prototype only after the interviews not before. A prototype built after real patterns emerge will be nearly pre-validated. I’m not opening Figma until the interview synthesis is done. The prototype I build then will reflect what people actually said, not what I assumed they needed.

↗ Rethink

A Bubble beta is still on the table but only if the interviews earn it. I won’t build a beta of a vague product. That’s how I’d end up back at the same problem. The beta decision happens in June, conditional on whether the interviews surface a problem slice specific and tight enough to build in 3–4 weeks not because the calendar says so.

+ New

I’m documenting this pivot as it happens. A case study that shows how I discovered the prototype was too broad and how I reframed it is more valuable than one that pretends the path was always clean. I’m capturing decisions, reasoning, and what changed in real time. This pivot is part of the work.

◦ Timeline

Everything wraps by end of June 2026. March: Market research + niche hypothesis (2 weeks) Mid-March → May: 5 interviews per week Early April: Synthesis checkpoint at ~20 interviews May: Full synthesis + problem reframing Late May → June: Prototype rebuild June: Beta decision (Bubble yes or no)

After structured discovery, 5 research briefs, and a full pivot, Whealth has been renamed fuchcia, narrowed from a broad women’s health platform to a focused, AI-native app for women with endometriosis in France, with a specific lens on migrant and non-Western women. Here’s what changed, and why.

The original name covered everything and therefore nothing. After research confirmed that the real, unmet, fundable gap was endometriosis care for migrant women in France, the scope narrowed. The name followed. fuchcia, the c borrowed from my middle name, Francia signals visibility, defiance, and specificity. Linked to the colour fuchsia: bold, unapologetic, impossible to ignore. The colour my mother dressed me in as a child, before I knew what it meant to take up space. It is not a rebrand. It is a precision cut.

✓ Done – Discovery research · 5 briefs

✓ Done – Pivot · Rename · PRD v1.1

✓ Done – Prototype v5 · Maze-ready

✓ Done – Maze testing · PRD v2.2 · cut to local-first

✓ Done – Local-first beta released · 2 July 2026

→ Now – One build a month, chosen from my own needs

Type, Decision, Rationale, Outcome, Next action

✓ Keep

Didn’t kill the idea.

Research confirmed real emotional and financial pain, 7–10 year diagnostic delays, structural erasure of migrant women, no culturally adapted app in France. What was broken was scope, not insight.Reframed the problem. Did not abandon it. Result: fuchcia.

↗ Sharpen

Narrowed to one nicheThe original Whealth problem spanned chronic illness, mental health, gynaecological health, geography, and community (5 products in one). Research across Reddit, Facebook, academic papers, Ivy League and European sources identified endometriosis in migrant women in France as the most urgent, most underserved, and most defensible niche.Hypothesis confirmed: “Women with endometriosis in France especially, migrant and non-Western women, lack accessible, culturally adapted health support in their language.” This is now fuchcia’s mission statement.

✓ Keep

Deep market research, time-boxed5 research briefs completed: Reddit, Facebook, Academic 2025, Ivy League, European & French. Competitive landscape mapped across 10 apps (Phendo, Clue, Lyv, ENDOless, LUNA, Flutter, MyFLO, Follow Metrios, MyEndo’App, Flo). Lyv Endo and ENDOless identified as most serious French competitors, both have structural blind spots: monolingual, monocultural, mutuelle-gated.Research complete. No competitor serves migrant women with endo in France in their language. fuchcia’s gap is confirmed and unfilled.

✓ Keep Async research. No live interviews needed at this stageDiscovery was conducted entirely through existing data: Reddit threads, Facebook groups, academic papers, app store reviews, and competitor analysis. This was a deliberate choice suited to my neurodivergent working style. Zero live social exposure required, full research depth achieved.Live interviews were deprioritised during this period, personal circumstances made sustained outreach difficult to maintain, and I chose to keep the project moving rather than stall it. Async methods (Reddit, Facebook groups, academic papers, app reviews) delivered the same depth of signal without requiring live social exposure. Cultural validation surveys remain on the roadmap for the beta phase.

★ NewBuilt

PRD v1.1 from prototypeA PRD was built directly from prototype v5 and the research synthesis, covering 15 features, AI strategy across 3 phases, GDPR compliance plan, business model (B2C freemium + B2B + Research-as-a-Service), risk register, and a roadmap to public launch Q1 2027.PRD v1.1 active. Status: Maze testing in progress. Next: iterate to prototype v6 based on results.

★ New

Prototype built AI-native, with Claude

fuchcia is not an app with an AI feature. AI is the layer that makes every feature intelligent and proactive: flare prediction, personalised daily insights, auto-generated doctor summaries, Endotest eligibility guidance, smart reminders. Built entirely with Claude from the first research session to the PRD.AI integration roadmap defined across 3 phases: MVP (flare prediction, doctor prep), Beta (community moderation, real-time translation), V2 (conversational care agent, specialist matching).

↗ Sharpen

Removed pricing from Maze testPrototype v4 included a full pricing/Full Access screen. This was removed in v5 and replaced with a neutral placeholder (“Full Access coming soon / This feature is not available in this test”). Reason: price anchoring distorts usability data. When users see a price mid-task, they evaluate value instead of navigating, and drop-off data becomes uninterpretable.Pricing will be tested separately via Van Westendorp survey or a fake door test, not through Maze. Prototype v5 is Maze-ready.

✓ Keep

Test before buildingThe original Whealth plan was correct: prototype first, validate, then build. What changed is the depth of validation, Maze usability testing (task completion, drop-off, misclick rate) AND a cultural validation survey (remedies, community format, sex education tab, nutrition) before any backend work begins.The beta build was gated on Maze task completion >70% across all P0 flows, more than 30 cultural survey responses, and all critical usability issues resolved.

Superseded: v2.2 cut the backend entirely, so there was no backend investment left to gate, and the beta shipped on 2 July 2026.+ AddDocument the pivot as the case studyThis case study shows I discovered the prototype was too broad, narrowed it to one niche, renamed it, built a PRD, and tested it before building the full app. It is more compelling. This pivot is the work.You are reading it.◦ TimelineRevised timeline to Q1 2027Original June 2026 deadline was for a Bubble beta of a broad app. fuchcia is a narrower, deeper, AI-native product. The revised timeline reflects the depth of testing required before any backend investment.

Superseded, twice over. The plan at this point read: Mar 2026 Maze + cultural survey · Q3 2026 beta build with a minimum viable backend · Q4 2026 closed beta, 50–100 users · Q1 2027 public launch · Q2–Q3 2027 V2 and B2B. None of it held. PRD v2.2 cut the backend, so the beta shipped early and free on 2 July 2026 with nothing to certify. Then in August 2026 dated roadmaps were dropped altogether, in favour of one build a month chosen from need. Both changes are set out below.

After Maze testing and PRD v2.2, fuchcia changed shape. The AI-native, backend-first product became a deliberately smaller, local-first beta, one where a woman’s health data never leaves her own device. Here is what changed, and why the smaller version is the stronger one.

What fuchcia actually is: privacy-native, not AI-native. The product is trust, and trust lives in the architecture, local-first, no backend, nothing leaves your device. AI isn’t the core here. It’s a single, optional feature: an on-device summary that helps you walk into a doctor’s appointment prepared. Remove that feature and fuchcia still does its job. That’s the tell. The thing I can’t remove, the privacy, is the product. The AI is a tool inside it, running on your phone, seeing nothing I don’t.

In my first PRD I called fuchcia “AI-native from day one”. I was wrong, not about the ambition, about the word. AI-native doesn’t mean I designed it with AI in mind, or that I build with AI every day. Those are three different things, and I’d collapsed them into one. Building with Claude and Lovable is AI-assisted development, how I work, not what I ship. An on-device summary is AI-embedded, a feature inside the product. AI-native means the product disappears the moment you remove the model. By that test, fuchcia isn’t AI-native. It’s privacy-native with an AI feature. Smaller claim. Truer one. And the one to defend.

Backend cut; data stays on the device.Privacy-first scope, staged AI, bootstrapped model.Released 2 July 2026; one anonymous Tally form.14 opens, 0 responses. The form is retired and the gate is answered. What happens next is below.

The first plan was AI-native, with a backend and a Q1 2027 launch. PRD v2.2 cuts the backend entirely: a local-first beta where nothing is collected, shipping 2 July 2026. Smaller scope, sharper promise.

Storing symptom data in France makes it GDPR Article 9 special-category data and triggers HDS certification, a DPIA, and likely a DPO. Not realistic for a solo builder on a beta timeline. So fuchcia removes the need to store it. It can’t leak or sell what it never collects.

fuchcia runs entirely in the browser, on-device storage, doctor-prep PDF generated on the phone, no server ever receives health data. Privacy isn’t a workaround here; it’s the front-end craft I trained in, turned into the trust model.

Beta released 2 July 2026, local-first and backend-free. What happened in the five weeks after is below.

v2.2 trades the big build for a smaller, honest one. No backend, no account, no tracking, health data lives only on the user’s device and is never sent to me. The privacy promise stopped being a constraint to work around and became the product’s strongest position in the AI era.

Type, Decision, Rationale, Outcome

→ Sharpen

Cut the backendServer-stored health data triggers GDPR Article 9, HDS certification, a DPIA and likely a DPO out of reach for a solo builder on a beta timeline.Local-first beta; data never leaves the device.

✓ Keep

Privacy as the position

You can’t leak or sell what you never collect. The strongest, most honest stance in the AI era. New promise: Your endo. Your data. Your space.

★ NewFront-end is the trust modelClient-side app, on-device storage, doctor-prep PDF generated on the phone, no server ever receives the health dataPrivacy by design, not by policy.

→ Sharpen

AI, staged honestlyThe beta uses on-device rules, a gentle flare-ahead nudge not an LLM. A stateless proxy that stores nothing comes later, funded by revenue.Private, offline, free, never diagnostic. Corrected further after the five-week audit, below.

✓ Keep

Bootstrapped, builder-ownedNo investors, no VC, near-zero running cost. Simplicity and transparency as a deliberate choice, not a phase.Free forever, plus a small, honest paid tier, sustainable by design.

★ New

Measure without watchingNo analytics, no tracking. Success is read only from voluntary, anonymous feedback.A single Tally form; ~20–30 substantive responses set the go / no-go gate.

It drew 14 opens and 0 responses. The form has been retired and the gate is answered, below.◦ TimelineBeta 2 July 2026Local-first build now; learn over summer; a compliant, paid-for build only if the beta validates.Funded later by revenue or grants never investors.

Where AI could add value: rephrasing a symptom note into something clearer before a doctor’s visit, and, if funded later, a more capable assistant for doctor-visit prep that works across all four supported languages.

What data it would need: only the note text itself, processed on the device and never transmitted anywhere. For the deferred cloud mode, whatever a user chooses to send in that moment, processed statelessly and stored nowhere.

What I deliberately scoped out, and why: any server-side AI call, any diagnostic claim, and any model call at all for the “flare-ahead” nudge. That nudge is a plain rule (rising pain trend surfaces the First Aid Kit), not a model, because a rule solves it as well as AI would, more cheaply, with zero hallucination risk, and identically across English, French, Malagasy, and Tagalog.

Correction, August 2026. I went to check this claim instead of repeating it, and it did not survive. The rephrase feature called a browser API that is absent in the browsers people actually use, so it had never run for anyone: every tap silently returned a whitespace tidy dressed as an AI result. The doctor-summary button did work, and it wrote a shortened version over the user’s original note with no way back. Availability was being detected by checking whether an API name existed rather than whether a model could run, so the feature was offered to browsers that could not deliver it. All three are now fixed: nothing overwrites your text, the original stays on screen, every button is labelled with what it genuinely does, and detection is capability-based. On-device AI is a capability some devices happen to have. It is not something fuchcia can promise everyone, and it is no longer presented as one.

The beta released on 2 July with one decision rule attached: roughly 20 to 30 anonymous responses would settle whether it earned its next build. Five weeks later the answer was zero. Here is what the numbers actually said, what I built anyway, and why the measure changed rather than the mission.

2 July. Local-first, no account, nothing collected.225 visitors, 10 referral visits, 14 form opens, 0 submissions.One build a month, chosen from what I actually need. Each build gets a written update.Since diagnosis, treatment is what I live with daily, in the way cycles were before.

225 visitors to 5 August, 156 of them in France, and 10 visits from everything I had published. The feedback form was opened 14 times and submitted zero times, at an average visit of 18 seconds. Nobody typed a word. Not a placement problem and not a length problem: it was asking for feedback from people who had not used the product.

I left the app I had used for more than ten years and moved my own health tracking onto fuchcia permanently. It is now my tracker and the record I bring to my medical file. The mission has not moved and neither has the audience. What I count has: durability instead of adoption.

I checked which browser API each AI button called. One had never run at all, because the API it depends on is absent. The other worked, and quietly wrote over the symptom note underneath it. Four audits had missed both. One console command caught them.

Type, Decision, Rationale, Outcome

→ Sharpen

Retired the feedback form14 opens, 0 submissions, 18 seconds average, and not one person started answering. Neither burial nor length explains that. It asked something of people who had not yet used the product.Removed. The contact page on this site takes its place, with no new address collected.

★ New

Built for myself firstI am the person the product is about and I now depend on it daily. Building for a user who is not there is how a roadmap drifts.Success measured as durability, not adoption. Mission and audience unchanged.

★ New

Closed the data-loss defectThe app told users to export a backup that nothing in it could read back. For an architecture whose whole premise is one copy on your device, one-way portability was the most serious thing wrong with the product, and worse than a missing feature because the app actively told people they were protected.Import shipped. An export can now be restored, merging by date instead of overwriting.

★ New

Migrated ten years of history. My cycle history sat in an app I no longer wanted to depend on. Its export turned out to be a 400+ page printable report rather than a data file.Extracted and verified row by row against consecutive period starts, then imported.

★ New

Made “not currently cycling” a first-class stateContinuous treatment suppresses periods. A tracker that counts to day 600, or nudges you to log a period you cannot have, is broken for exactly the women it is built for.Shipped, alongside back-dated entry so that flare days can be recorded after the fact rather than lost.

↗ Correct

Downgraded the AI claim

One AI button had never executed, because its browser API is absent in the browsers people use. The other summarised a symptom note and overwrote the original with no way back. Availability was being detected by checking whether a name existed in the browser rather than whether a model could actually run.

Fixed: nothing overwrites your text, the original stays on screen, every button is labelled with what it genuinely does, and detection is capability-based. On-device AI is now presented as a capability some devices have, not as a headline feature of the product.

◦ Roadmap

One build a month, chosen from what I needA dated roadmap suited a product chasing a launch date. This one has a user whose needs move with her condition, and a monthly build budget. Committing to features a year out would be guessing.

Each month: measure, choose, build, write it up. Each build gets a written update.

I’m open to discussing permanent PO/PM roles. Let’s talk about what you’re building.