Part 2 of my sideloading series — read part 1.

Problems with period trackers

Nearly a third of women in the US report using an app to track their period. That’s like, 50 million people.

Yet the period tracking app space is pretty fraught. Of course, there are the usual someone-else-made-this problems of way too many settings and omnipresent ads.

But they have their own unique issues, too:

• First off, someone else now owns your private reproductive data. That’s pretty gross on a surface level, but it goes beyond a vague ick. Using any app involves a trade-off between privacy and convenience, but these apps are basically giant fertility data aggregators with a big incentive to sell that data. A 2019 investigation found that the most popular period app Flo “informed Facebook when a user was having their period or if they informed the app that they intended to get pregnant”. Inexcusable.
• Another gripe I have with period apps is their girlish designs. Can adult women not have a sophisticated-looking user experience when it comes to their bodies?

I spent a few hours last weekend building & deploying my own custom period tracker app.

Note: The screenshots in this post contain AI-generated test data for demonstration purposes.

Period Tracker (the Status Quo)

Going back all the way to 2014, I’ve used an app called Period Tracker for logging two things:

1. Period start date
2. Period end date

While the app can do that, it does so within a childish UI while also constantly shoving in your face that it can do WAY MORE than that! It can track your weight, your ovulation cycles, your cravings, your moods! Please open our mood tracker! Please add your temperature!!!

Check out the UI below. By the way, this thing has 73k app store reviews. This isn’t a niche product.

App store apps are designed to be used by the broadest possible swath of people. That leads to two common annoyances for any given individual:

• Way too many settings. Settings really only exist because many different people will be using an app. Some people like dark mode, and some people like light mode, but any individual person is relatively unlikely to be switching back and forth between the two. Same for notification settings, units, and so on.
  • When sideloading, you rarely need to implement settings. Make the theme dark if you like dark mode. Use Fahrenheit and MM-DD-YY if you’re in the US. Don’t include pregnancy mode if you can’t get pregnant.
• Way too many features. Having a lot of features increases perceived value for users, even if a given user is unlikely to use each individual one. Plus, different users use different subsets of an app’s features, so more features typically leads to more value overall. But, feature creep leads to bloat: any given user gets value from a smaller and smaller subset of overall functionality.
  • When sideloading, you can just keep the features you actually use. Add more later if you need. It’s surprising how much more zen it is to use an app that just does what you need it to do, and nothing more.

Introducing Moonthread

My main goal with Moonthread was to build a sophisticated, understated UI that does one thing: track your period. Like the counter app I detailed in my last post, Moonthread:

• Has no ads or upsells
• Has no settings
• Has a more refined design
• Has only the features I truly need

Moonthread also has a few upgrades over PeriodTracker:

• Stats page with “All” and yearly filters to see stats over time
• Clear visual difference between predicted & logged dates in the calendar view
• Infinitely scrollable calendar

And, the holy grail:

• I control my own data

As always, you’re welcome to clone or fork Moonthread to set up or create your own version.

Railway & data privacy

For the past couple of years, I’ve used Railway for all my deployments. I mentioned a moment ago that I “control my own data”. I imagine some people will object to that point; after all, Railway technically owns my data. They’d be right about that.

But, I don’t think they could deny that hosting your data in Railway is a big step up from logging it in a commercial period tracker. It has to do with the scale & ease of aggregation of the data.

To me, a crucial layer of protection is that Railway doesn’t have the same incentives to sell this data. Any given postgres instance could contain any kind of data, and it would take a lot of work to identify & aggregate the reproductive data across all provisioned dbs to package it for sale.

(According to Railway’s privacy policy, they “do not access, use, or analyze the contents of databases for analytics, aggregation or commercial purposes - access is limited to operating and maintaining the service.” That’s reassuring, though privacy policies tend to be aspirational rather than binding.)

That said, I don’t think my data is impossible to monetize, just harder to monetize. I don’t think Moonthread is the perfect solution.

Reflections

It’s been an amazing feeling, creating my own apps & making my data harder to access commercially. I’m still thinking through a lot of interesting questions.

For one, I’m still not sure if I want to maintain one deployment project with all my personal data (i.e. have a monorepo of all my apps together), or keep them as separate deployments. I see pros and cons. A monorepo obviously creates a single point of failure and probably wastes resources if updating one app constantly redeploys many others. But, it may save resources in the long term and make data analysis easier to keep different tables together in a shared db that many backends point to.

I also think a lot about cybersecurity when developing your own apps. While I do wonder if an app like Period Tracker even has a secure database (it’s probably pretty vulnerable - just a guess), that doesn’t make my own implementation any more secure. What’s nice in 2026 is that LLMs are pretty good at spotting common attack vectors like XSS, data exfiltration, and arbitrary code execution. Plus, you’ve got security by obscurity. My tiny period tracker app for one isn’t likely a target for anyone.

And, I’m intrigued by the idea of hosting my own server - truly owning my own data. It’s a lot easier said than done, I think. Some significant challenges I worry about include:

• Managing hosting, containerization, & provisioning myself
• Maintaining near 100% server uptime
• Managing drive & server redundancy

I would love to hear from anyone who has accomplished this robustly!

Regardless, I hope this post has been useful to you and that you’ll give sideloading a try.