Predicting how the next day will feel.

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.

The forecast had to work immediately and improve from there. We built it in two parts.

The first is a set of population baselines. Before a user has recorded anything, each of the seven measures is predicted from documented patterns on the same one to six severity scale the app uses, shaped by its own curve for each phase of the cycle. A new user sees a real forecast rather than an empty state.

The second is personalization. Seven independent Kalman filters, one for each measure, learn two numbers about the person using the app. The first is their baseline, the level they sit at normally. The second is their amplitude, how strongly they react as the cycle moves toward the late luteal phase. A prediction is the baseline plus the amplitude scaled by where they are in the cycle. Three genuinely different people, one who barely changes across the month, one who spikes sharply in the final week and one who runs elevated throughout, are all served by the same equation with no special cases.

Cycle length is predicted on its own terms. Bayesian inference treats what the user reported during onboarding as a starting position and shifts weight toward their recorded history as cycles accumulate, so the prediction stays sensible at zero recorded cycles, at one and at ten.

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 local database on the phone first. Writes are ordinary synchronous functions with no loading state, and reads are live queries that update as the data changes. Nothing in the interface waits on the network.

The detail that makes the account model work is that the local database stores no user id. A record written before signing in is identical to one written after. When someone does sign in, everything still marked as pending is pushed and the server stamps ownership from the authenticated session. Signing out stops the sync and leaves the local data untouched. 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.

After the prediction engine, this is the most heavily tested part of the app.

The avatar is how the app communicates emotional state, and it is a single Rive file driven by data binding rather than a set of drawn states.

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, mapped from the emotional load the model computes and set at runtime.

Customization is bound live rather than baked in. Hair, outfit, pose and accessories are enumerations in the Rive file, and skin, hair, socks, shoes and the colors of individual items are color bindings. Changing a color in the editor updates the running artboard directly.

One file serves two purposes. A full artboard drives the editor and a head-only artboard drives 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.

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.

Access runs on a subscription entitlement, which creates a problem worth naming. Someone can subscribe before they ever sign in, which means the purchase belongs to an anonymous identity and the account arrives afterwards. Transfer, expiration and purchase webhooks reconcile the two behind signature verification, so the subscription follows the person rather than the installation.

Promotional codes can also be issued from the admin application, either as lifetime grants or capped at a fixed number. A redemption counter with optimistic concurrency control means a capped code cannot be over redeemed when several people submit it at the same moment.

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 monorepo. The API is written in Hono and deployed as one serverless function, the database is Postgres through Drizzle, and authentication runs on Apple and Google sign in.

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.