Predicting how the next day will feel.
Moon Quest is a mobile app for people living with PMDD, PME and severe PMS. It forecasts how the days ahead will feel rather than recording what already happened.
- Client
- Moon Quest
- Service
- Design and Development
- Year
Background
Helene Choo is a storyteller, marketer and women’s health advocate with a decade in brand strategy behind her, and for more than ten years she lived with PMDD that nobody had named. A diagnosis finally came in 2023, and most people with the condition wait that long. Her story of getting there is the reason Moon Quest exists.
The app is a guide for people living with PMDD, PME and severe PMS. It forecasts how the days ahead are likely to feel from where someone is in their cycle, across seven measures aligned to the Daily Record of Severity of Problems, a validated instrument used in premenstrual research, and it presents that as a daily reading rather than a chart to interpret. The product is supportive rather than diagnostic, and it says so plainly to the people who use it.
WeaveLines worked with Helene from the first product decisions to the release on both stores. What follows is how the product took shape.
Research
Most cycle apps look backward
The work began with a close look at the cycle apps already on the market. Nearly all of them are trackers. They record what has already happened, they reward unbroken streaks, and they have little to say about the day ahead, which for someone with PMDD is the day that matters.
PMDD is cyclical by definition. The hard days tend to arrive in a pattern, which means they can be anticipated, and anticipation is worth more than documentation to the person bracing for them. That finding became the product goal. Moon Quest would treat the forecast as the product rather than as a feature inside a log, and it introduces itself as the first cycle app that isn’t a tracker. No streaks, and no guilt for the days nobody checks in.
That one decision shaped everything after it, from the architecture to the model to the interface, and it is the reason the app opens on a prediction rather than on a calendar.
Challenge
Being useful before it knows anything
A forecast carries a problem a log does not. It has to be useful on the very first day, before the user has recorded anything at all, and it has to grow more accurate with use without ever appearing to have been guessing at the start.
The app also had to work in the moments it exists for. Someone reaching for it on a difficult evening should not need a connection or an account to see their forecast.
Our solution
We took Moon Quest from a prototype shaped with Helene to an app released on both stores. The engagement covered product design, the prediction model, the mobile application, the content platform and the backend behind them.
01Product Design
Read moreA working prototype iterated quickly with Helene until it matched her vision, then documented for the build.
02The Forecast
Read morePopulation baselines give a new user a real forecast on day one, and the model makes it theirs as they check in.
03Local-first Architecture
Read moreEvery read and write hits a local database first, so the app works fully offline and an account is optional.
04The Avatar
Read moreA single Rive file carries ten expressions and full customization, bound to live data rather than drawn state by state.
05Learning and Progress
Read moreContent is authored in a web dashboard and read offline on the device, with a progress loop that ends at the avatar.
06Subscriptions and Access
Read moreA subscription bought before signing in follows the person to the account they create afterwards.
07Platform and Release
Read moreOne TypeScript monorepo behind an iOS app, an Android app, an admin application and a serverless API.
01Product Design
Fast iterations toward her vision
The prototyping and design were done in Replit, in fast iterations. We improved and changed the design based on Helene’s feedback, and each round closed the distance between the prototype and the product she had in mind.
In some meetings the adjustments happened live. A flow could be changed and judged on the spot, so decisions were made looking at the real thing rather than imagining it from a description. Iteration that cheap changes the conversation, because trying an idea costs minutes and discarding it costs nothing.
Once the shape of the product was settled, it was written down. Specifications and PRD documents were produced from the validated design, so implementation started from a documented source of truth rather than from memory of what had been agreed.
02The Forecast
Useful on day one, personal by month three
The forecast had to work immediately and improve from there, and we built it in two parts.
The first is a population baseline. Before a user has recorded anything, each of the seven measures is predicted from documented patterns of how symptoms move through the cycle, so a new user sees a real forecast on their first day rather than an empty state.
The second is personalization. As the user checks in, the model learns two things about them, the level they sit at normally and how strongly they react as the cycle moves toward its hardest days. Someone who barely changes across the month, someone who spikes sharply in the final week and someone who runs elevated throughout are all served by the same model with no special cases. Cycle length is predicted the same way, starting from what the user reported during onboarding and leaning on their recorded history as cycles accumulate.
Built into the model
- An honest confidence figure
The personalization percentage on the home screen is the number the model actually uses. It is computed from how much of each cycle phase the user has checked in for, and that same value decides how far the forecast leans on what it has learned rather than on population data.
- Curves matched to the phase
Each phase moves differently, falling away through menstruation, holding flat through the follicular phase, rising at ovulation and rising more steeply through the luteal phase, matched to documented symptom patterns.
- Entirely on the device
The whole model runs locally against local data, with no request to a server and nothing to wait for.
Barely changes
A low baseline and a small amplitude. The forecast stays close to flat all month.
Spikes in late luteal
A low baseline and a large amplitude. Calm for three weeks, then a steep rise.
Elevated throughout
A high baseline and a moderate amplitude. Raised all month, higher at the end.
- This person’s forecast
- Population baseline
- Late luteal
03Local-first Architecture
A local app that can optionally sync
Moon Quest is not an online app with an offline mode. It is a local app that can optionally sync.
Every read and write goes to a database on the phone first, so nothing in the interface waits on the network. Someone can use the app for months without an account and keep every day of it when they create one, with no migration step and nothing at risk. When they do sign in, everything recorded so far is sent to their account, and signing out stops the sync and leaves the local data untouched.
Where sync usually goes wrong
- Ordering
Records are sent in an order that respects their relationships, with period logs first because cycle detection depends on them, and deletions last.
- Deletions
A deleted day is marked as deleted and removed remotely, so it cannot reappear on the next sync.
- Failure
Anything that fails is retried a limited number of times with growing delays, rather than being lost or retried forever.
- Timing
Sync runs on events rather than background tasks. A local change is pushed a few seconds later, returning to the app triggers a pull, and signing in triggers a full synchronization.
After the prediction engine, this is the most heavily tested part of the app.
04The Avatar
One Rive file, bound to live data
The avatar is how the app communicates emotional state. It is a single animated character built in Rive, driven by the day’s data rather than drawn state by state.
The face reflects the day’s reading. Ten expressions run from grounded and content through strained and overwhelmed to distressed and in need of care, chosen from the emotional load the model computes.
Customization is live. Hair, outfit, pose, accessories and the colors of individual items change on the running character as the user picks them in the editor, and the same character serves the editor and the compact places such as the mood calendar, so there is no second asset to keep in step.
Inclusivity is part of the rig rather than an addition to it. A wheelchair pose is a first-class option alongside the standing pose, and the color ranges were revised specifically to widen who the avatar can look like.
05Learning and Progress
Authored on the web, read on the device
Lessons and insights are authored in a web dashboard, pulled by the mobile app and written into the local database so they can be read with no connection. New content can be published at any time without an app release, and the app checks for it against a daily freshness stamp rather than fetching on every launch.
Completing an insight earns Moon Experience, which raises a level, and Moon Points, which buy avatar accessories. The progress loop ends somewhere the user already cares about, which is the avatar they have made their own.
06Subscriptions and Access
A purchase that follows the person
Access runs on a subscription, which creates a problem worth naming. Someone can subscribe before they ever sign in, which means the purchase belongs to an anonymous installation and the account arrives afterwards. The platform reconciles the two, so the subscription follows the person rather than the phone.
Promotional codes can also be issued from the admin application, either as lifetime grants or capped at a fixed number, and a capped code cannot be over redeemed when several people submit it at the same moment.
07Platform and Release
One codebase behind four surfaces
Work began in December 2025, and Moon Quest shipped in March 2026 on the App Store and Google Play, from one TypeScript codebase built with Expo and React Native.
Three applications and six shared packages sit in a single codebase. The API runs as one serverless function on a Postgres database, and people sign in with Apple or Google.
How the platform holds together
- One typed API for three consumers
The mobile app and the admin application call the API through a typed client, so a change to a route becomes an error at build time rather than a failure someone finds in production.
- Deployments that skip themselves
Continuous integration inspects what a change actually affects and skips the server deployment entirely when the server is untouched.
- Errors visible in production
Exceptions are captured on both the server and the device, and every report points at real code.
- Privacy taken seriously
Local records carry no user id, and health-related data was removed from analytics.
Early users have called the product intuitive, friendly and supportive, and the in-the-moment breathing and grounding exercises, which we proposed, have been especially well received.
Keywords
- Product design
- Prototyping
- Mobile development
- Backend development
- React Native
- Expo
- TypeScript
- SQLite
- Offline-first
- Rive
- Hono
- Postgres
- Drizzle