It’s a familiar routine: you download a simple utility app, only to be met with a "Create an Account" screen. When it comes to something as personal as menstrual health, that barrier feels less like a feature and more like a privacy risk. Most period trackers on the market today sync sensitive health data to a cloud server, often sharing that data with third-party advertisers or leaving it vulnerable to breaches.
I decided to build PeriodTracker because I believed there had to be a better way to manage health data—one where the user actually owns their information and doesn't have to worry about who else is looking at it.
The Problem: Over-Engineered Privacy Risks
The frustration wasn't just about the data harvesting; it was the friction. If you’re trying to quickly log a symptom or check a predicted start date, navigating through ads or "premium" upsells is exhausting. I wanted a tool that felt like a native utility: fast, private, and completely out of the way.
Many users are rightfully concerned about how their health data is used. By requiring a login, developers create a honey pot of sensitive information. I wanted to see if I could build a full-featured tracker that required zero personal identification.
The Tech Stack
I kept the stack lean to focus on performance and reliability:
- React: For a responsive, component-based UI that feels like a mobile app.
- Tailwind CSS: To ensure the interface was clean and accessible without adding unnecessary weight.
- Date-fns: Handling date calculations is notoriously tricky in JavaScript. This library was essential for predicting future cycles based on historical data.
- Local Storage / IndexedDB: This is the core of the privacy model. All data remains in the user's browser.
The Technical Challenge: Prediction Without a Backend
Building an app without a traditional database presented an interesting technical hurdle. How do you provide a consistent experience without cloud sync?
By using the browser's storage, the data never leaves the device. However, this meant I had to write robust logic to handle data persistence and migrations. If I update the data schema in a new version of the app, I have to ensure the user's existing logs aren't wiped out. I implemented a versioning system for the local state to handle these updates seamlessly.
Another challenge was the prediction algorithm. Menstrual cycles aren't always exactly 28 days. I had to build a weighted average system that looks at the last several months of logs to provide a more accurate prediction for the next cycle, rather than relying on a static number. Writing unit tests for these date-heavy functions was the most time-consuming part of the development process.
Lessons Learned
- Privacy is a feature: Users respond well when they realize they don't have to provide an email address just to use a calendar. It builds immediate trust.
- Dates are difficult: Dealing with time zones, leap years, and the logic of "cycle length vs. period length" can easily break a tracking algorithm if you aren't careful.
- Simplicity is hard: Removing features is often harder than adding them. Keeping the UI focused strictly on logging and predicting took several iterations to get right.
Try it out
If you’re looking for a way to track your cycle without the baggage of a corporate account or constant notifications, you can use the web app here: https://periodtracker.getinfotoyou.com.
It’s a free tool designed to be helpful and out of your way. I’m always looking for feedback on how to make the predictions more accurate or the interface more intuitive for those who need to log symptoms quickly on the go.
Conclusion
Building PeriodTracker reminded me that not every application needs a complex backend or a data-mining business model to be useful. Sometimes, the most helpful tool is the one that stays out of your way and keeps your data exactly where it belongs: with you.
Top comments (0)