The latest articles on DEV Community by Alfred Chaos (@alfredchaos). https://dev.to/alfredchaos https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4169957%2Fe9cf424b-f7e6-48c2-852c-e6a4dca142f7.jpg https://dev.to/alfredchaos en Alfred Chaos Thu, 08 Oct 2026 00:21:54 +0000 https://dev.to/alfredchaos/i-built-a-period-tracker-that-never-asks-for-an-account-140o https://dev.to/alfredchaos/i-built-a-period-tracker-that-never-asks-for-an-account-140o <p>This week I shipped the first public version of Mori, an Android period tracker. The product rule I started with was simple: no account, ever, for the core features.</p> <h2> Why that rule </h2> <p>Period data is some of the most sensitive stuff on a phone. In most tracker apps it ends up on a company server, attached to an email, behind a login the app demands before it even opens. That model has real-world consequences — after Roe v. Wade fell, the White House literally warned people about period tracker apps because server-side reproductive data can be subpoenaed.</p> <p>So I built the opposite default: records live in a local SQLite database on the phone. Without cloud sync, nothing ever leaves the device. There is no signup screen. You open the app, mark your period days on the calendar, and it gives you a prediction window for next time — computed on-device from your own history, with an explicit confidence label and an explanation of what it based the estimate on. Predictions are deliberately boring: deterministic math over your records, not a black-box model.</p> <h2> What's in it </h2> <ul> <li>Calendar + cycle ring, tap to log/unlog dates</li> <li>Next-period range + ovulation/fertile-window estimates, always labelled as estimates (never as medical certainty)</li> <li>Optional local notifications that don't put health words in the notification body</li> <li>Full export and "delete everything" on-device</li> <li>English + Chinese</li> </ul> <p>The app itself has zero analytics. There is exactly one analytics script in the whole product, on the marketing landing page (GA4), because I needed to see if anyone found the thing.</p> <h2> The paid part </h2> <p>The model is buy-once, not subscription. Everything above is free forever — logging, history, predictions, export, delete, turning reminders off. The only thing that costs money ($3.99, one-time) is optional encrypted cloud sync. The server side is Go + Postgres; the snapshot is encrypted on the device before upload, and the backend never sees plaintext records. I didn't call it "end-to-end" in the docs because the server can unwrap the DEK during account recovery — being honest about that felt like the whole point of the exercise.</p> <h2> State of it </h2> <p>It's a side-loaded APK from the site (<a href="https://www.moricycle.com/" rel="noopener noreferrer">https://www.moricycle.com/</a>) — not on Google Play yet, which is the main friction right now. iOS is planned, not started.</p> <p>Ask me anything about the sync crypto design, the deterministic prediction approach, or why I spent a month arguing with myself about the word "private" on the landing page.</p> privacy android indiedev