Why I Built a Privacy-First Period Tracker: Client-Side Predictions Without the Cloud

We track everything today: steps, screen time, and budgets. But when it comes to tracking a menstrual cycle, the options are surprisingly frustrating. For years, the choices have been divided into two camps: building a complex manual spreadsheet yourself, or handing over highly sensitive health data to corporate databases.

Here is a breakdown of what it looks like to do this the hard way, why I built a middle ground, and the technical decisions behind it.

The Hard Way: Spreadsheets vs. Privacy Concerns

If you want to track your cycle privately, your first instinct might be a custom spreadsheet. I have seen spreadsheets with complex conditional formatting, date calculations, and rolling averages designed to predict the next cycle start date.

While spreadsheets respect your privacy, the developer experience and user experience are painful:

• Mobile friction: Opening a giant Google Sheet or Excel file on a phone while dealing with a tiny virtual keyboard is a frustrating experience.
• Maintenance overhead: One accidental swipe can delete a cell formula, breaking the prediction logic.
• Lack of clean UI: Logically viewing cycle trends or logging daily symptoms like mood or cramps becomes cluttered.

The alternative is using commercial apps. But in exchange for a polished UI, these services often demand that you create an account, sync your data to the cloud, and agree to lengthy privacy policies that allow them to monetize your health trends. For many health-conscious individuals, this is a non-starter.

The Middle Ground: A Local-First Web App

I wanted something that combined the convenience of a modern app with the privacy of an offline spreadsheet. That is why I built PeriodTracker.

The premise is straightforward: you load the site, log your cycles, and see predictions. There are no accounts, no logins, and no servers storing your information. Everything stays in your browser.

The Tech Stack

I decided to keep the stack simple to ensure long-term maintainability and speed:

• Frontend: Plain HTML, CSS, and modern client-side JavaScript.
• Storage: localStorage for quick retrieval of cycle histories and preferences.
• Portability: A JSON-based backup system allowing users to export their data to a local file and import it on other devices.

By avoiding a backend database, the hosting is static, cost-effective, and secure by default. There is no server to hack, and no database for anyone to leak.

Technical Challenges & Implementation

Building a local-first application without a backend presented some interesting architectural challenges.

1. Calculating Predictions Locally

Without a server to run calculations, all cycle predictions must run efficiently in the user's browser. I implemented a moving average algorithm that analyzes the user's last six cycles to predict the next start date and the corresponding fertile window.

Here is a simplified snippet of how the cycle length average is calculated:

function calculateAverageCycleLength(cycles) {
  if (cycles.length < 2) return 28; // Default fallback

  let totalDays = 0;
  for (let i = 0; i < cycles.length - 1; i++) {
    const current = new Date(cycles[i].startDate);
    const next = new Date(cycles[i + 1].startDate);
    const diffTime = Math.abs(next - current);
    const diffDays = Math.ceil(diffTime / (1000 * 60 * 60 * 24));
    totalDays += diffDays;
  }
  return Math.round(totalDays / (cycles.length - 1));
}

2. Data Loss Prevention

The biggest risk of client-side tracking is that if a user clears their browser storage, they lose their history. To mitigate this:

• The UI actively reminds users to download a periodic backup.
• The import/export feature parses uploaded JSON files, validates the structure to prevent malformed data injection, and populates the local state.

Lessons Learned

Building a zero-database application taught me the value of friction removal. When users do not have to fill out an email form, verify their account, or set a password, they are far more likely to engage with the tool.

Furthermore, local-first applications offer high performance. Because there are no API calls or server round-trips, the UI transitions are instantaneous.

Conclusion

You do not need a complex backend or invasive data collection to build a functional utility. If you are looking for a straightforward, private way to track your cycle, check out the live version at PeriodTracker and let me know your thoughts in the comments.