Development of Zorya: Privacy-First Pregnancy Tracker App

Product design, research, and 0→1 ownership. iOS, live on the App Store.

I built a pregnancy tracking app with no backend, no accounts, and no analytics inside the app itself. Then I had to figure out how to run a product, make decisions about it, and know if it was working, without ever being able to see what a single user was doing inside it. That constraint shaped almost every decision in this case study, including ones that had nothing to do with data.

Zorya is a privacy-first pregnancy tracker for iOS. It is built and owned by me, solo. No design manager, no researcher, no engineer, no team to hand work off to. I ran product, research, UX, visual design, copy, and App Store operations myself, and directed all engineering execution through AI-assisted development (Claude Code), which I treated as my engineering partner rather than a shortcut.

I am a product designer by trade, and I was pregnant with my second child while building this. The idea did not come from a market gap I spotted professionally. It came from being frustrated, personally, by how casually the pregnancy apps I was using treated some of the most sensitive data a person generates: weight, symptoms, cycle information, due dates. I looked into it properly and found that the frustration was justified. Flo, Glow, and Ovia, the three biggest names in the category, all have documented privacy violations on record.

That gap between what these apps promise and what they actually do became the whole premise of Zorya. Not "a calmer pregnancy app." A pregnancy app that cannot betray you, because there is nothing to betray.

I did not want to build this on a hunch, even a well-founded one, so before committing to the full build I ran a proper study. I designed a 14-question survey covering current app usage, past pregnancy logging, medical record storage habits, and labor tracking, and worked through three research platforms before running it. Maze was the obvious choice but too expensive for a solo pre-revenue project. Lyssna looked promising until I hit a $199/month paywall, and its screener logic could not reference earlier questions cleanly, which forced me to restructure the survey. I ended up on Prolific, paying per participant instead of for a subscription, and fielded it to 53 pregnant and recently postpartum women.

The findings did more than validate the idea. They sharpened it.

96% had used a pregnancy app with a documented privacy violation.

70% rated local-only data storage as extremely important to them.

71% wanted the ability to look back at past pregnancies, not just the current one.

45% found switching apps between tracking and labor disruptive.

The real insight was not the 70% who said privacy mattered. It was the 96% who said it mattered and were already using an app that had violated it anyway. People were not choosing bad apps because they did not care. They were choosing them because no better option existed, and because privacy in this category has always been a policy on a page, not something structural. That gap, between stated values and available choices, is what I decided to build into rather than around.

It also told me what to leave out. I deliberately did not build bump photo galleries or appointment schedulers, both of which are close to default features in this category. They are useful, but they pull the product toward being a general life-admin tool. I kept Zorya narrow: the things a woman logs about her own body and her own pregnancy, and nothing that turns it into a shared calendar or a photo backup service.

Two principles carried the entire product, and I wrote them down early so every later decision could be checked against them instead of relitigated from scratch.

Architecture, not a policy. Privacy is not a promise I make in a settings screen. It is a structural fact: there is no backend to breach, no account to hack, no server logs to subpoena. I use this phrase sparingly in actual copy, because saying it too often turns a hard architectural choice into a marketing line, which is exactly the kind of thing I was trying to build against.

Mirror, not doctor. The app reflects what a user logs. It does not interpret it, score it, flag it, or predict anything. No AI diagnosis, no risk scoring, no push notifications nudging someone about a symptom. This constraint sounds simple until you are actually deciding what a feature should do, and it disqualified more ideas than anything else in the product.

I enforced that second principle against myself more than once. While designing an Insights dashboard, I built a first pass that included a mood-tracking chart, a reasonable-looking feature that every competitor has. Reviewing it against the actual database schema, I realized mood was not a logged data type at all: I had designed a chart for data the app does not collect. I could have added a mood field to make the mockup true. Instead I pulled the mood card entirely and replaced it with a sleep chart, because sleep was already something Zorya honestly captured. Small decision, but it is the kind of discipline that keeps a "mirror not doctor" principle from quietly eroding one convenient feature at a time.

Phase 1: building the core. Weight, blood pressure, symptoms, sleep, and free-form notes as the only entry types. A kick counter that activates at week 27. A contraction timer with 5-1-1 labor detection that activates at week 36. Forty weeks of milestone content. A pregnancy archive so a second or third pregnancy does not erase the first. Every screen had to justify its place against the mirror-not-doctor rule before it got built.

Phase 2: pricing the wrong way first. Zorya launched with a 28-day trial and a one-time Lifetime Pass purchase gated behind week 9. It converted poorly. My first instinct was that the problem was philosophical, that asking for money at all sat uncomfortably against a product built on trust and gentleness. I made myself separate that from the actual mechanism before acting on it. With no in-app analytics, I could not run a funnel analysis, so I reasoned it through instead: a 28-day trial measured from signup, in a product whose most valuable features unlock much later in pregnancy, likely expired before people ever reached the moment that would have convinced them to pay. That reframed it from a values problem to a timing problem, and those two problems call for completely different fixes.

Phase 3: the pivot. I removed the paywall entirely and rebuilt monetization around a voluntary tip jar living permanently in Settings, three tiers, no rewards or unlocks attached to any of them. One rule I set early and did not compromise on: never prompt for a tip at the end of a pregnancy. That is the single most vulnerable moment in the entire product, and using it as a conversion opportunity would have contradicted everything Zorya claims to be. Tips only ever surface where a user goes looking for them, and every tier ends at the same quiet thank-you screen, signed with my name.

Phase 4: saying no to the obvious next feature. Postpartum tracking is the natural next chapter, and while scoping it I looked seriously at what competitors were building there: AI companions offering mental health insights, mood-based screening, even AI-driven crisis reassurance. It is genuinely open market territory. It is also exactly the kind of clinical, high-liability ground I had ruled out from day one, and the idea of an AI reassuring a vulnerable new mother at 3am with no real safeguards behind it did not sit right with me at any level, business or otherwise. I scoped a postpartum tail instead: a calm week counter, self-logged recovery, no scoring, no AI, no mental-health claims. Same mirror, extended forward a few months.

Zorya today is a free iOS app, in English and Croatian, that tracks a pregnancy through 40 weeks with weight, symptom, sleep, and note logging, a kick counter, a contraction timer with labor detection, milestone content, a multi-pregnancy archive, and a rule-based Insights dashboard that surfaces patterns in a user's own logged data without ever interpreting them. All of it runs on-device through Expo and SQLite. Monetization is a permanent, low-pressure tip jar in Settings (still waiting to be published by app store). There is no login screen anywhere in the app, because there is nothing to log into.

This is the section where the app's core promise works against me as a case study. Because Zorya has no in-app analytics by design, I cannot show a funnel or a retention curve. What I have instead are the honest, indirect signals available to a privacy-first product:

5.0 average rating from organic reviews across five countries (Canada, Croatia, Netherlands, Sweden, United States) within the first weeks post-launch, with no paid acquisition running.

Early App Store Connect funnel data showing organic growth over two weeks: impressions roughly 894 to 1,480, product page views 142 to 166, downloads 19 to 25. These are small, early-stage indie numbers, not a hockey stick, and I am naming them as exactly that.

Review language from real users independently echoing the product's core claims back, unprompted: local-only storage, no account required, one-time or optional payment. That is a stronger signal than a rating number on its own, because it means the positioning is landing as intended, not just being tolerated.

The 53-person survey itself functioned as a pre-launch impact signal: quantified demand and validated the core architecture decision before a line of code shipped, rather than after.

What I would measure next, if I am honest, is the uncomfortable question this product forces: how do you responsibly grow something you have deliberately chosen not to instrument? The answer I am working from now is qualitative by necessity: App Store review sentiment, a planned community channel for direct feedback, and periodic follow-up surveys, rather than conventional product analytics.

That is not a workaround I am unhappy with. It is the actual cost of the architecture-not-a-policy decision, made visible in how I now have to work.

There was no one else to make these calls, which meant every one of them was mine and stayed mine. I chose the research platform based on cost, not convenience. I set the pricing model, watched it underperform, diagnosed it as a timing problem rather than a values problem, and rebuilt monetization around that diagnosis instead of my first instinct. I turned down a real, low-competition market opportunity in postpartum mental health because building it well would have meant breaking the one rule the entire product is built on.

I also had to build a way to lead a project with no one in the room. Every engineering decision was directed through detailed, sequenced prompts, and I kept a persistent project document (CLAUDE.md) as the single source of truth for design tokens, schema, and prior decisions, specifically so the product's logic did not live only in my head between sessions. That habit, of writing decisions down so they outlast the person who made them, is the same discipline a design lead would apply to a team. I just applied it to myself.

The biggest thing I got wrong early was assuming the paywall's underperformance was a values conflict, that asking for money somehow betrayed the product's tone. It was not. It was a mistimed trial window. I am glad I checked that assumption before rebuilding the whole monetization model around the wrong diagnosis, because "we should never charge for this" and "we charged for this at the wrong moment" lead to completely different products.

The thing I still have not fully resolved is the tension between privacy and visibility. I built a product that cannot see its own users by design, and I believe that is the right choice. But it means every future decision, what to build next, what is actually working, what is quietly failing, has to be made with less information than almost any other product I have worked on. I do not think that gets easier. I think it is the permanent price of the thing that makes Zorya worth building in the first place.

If there is one thing this project taught me, it is that privacy claims are cheap and architecture is not. Anyone can write "we protect your data" into an app description. Very few products are actually built so that the claim is structurally true even if the company disappears tomorrow. That is the harder, less flattering version of the work, and it is the only version I trust anymore.