I built a period tracker with no server. Here's why that's harder than it sounds.

"We take privacy seriously." I have read that in privacy policies of companies that got sued for selling user data six months later. So is "privacy first period app." So is "your data is safe." The phrases mean nothing until the architecture backs the words.

So when I set out to build Bleed, I skipped the phrases. I did not want to write another privacy policy that sounded like everyone else's. I wanted to build a private period tracking app in a way that the privacy question could not really be asked, because there was nothing to ask about. No account. No cycle data to sell, share, subpoena, breach, or hand over.

That decision took about ten minutes to make. Everything after that has taken years.

Here is what "no server" actually cost me to build.

Why no server in the first place

Data that does not exist on your server cannot be stolen from your server. That sentence is the entire thesis.

Most period trackers handle privacy one of two ways. Store the data on a server and encrypt it in transit (Flo, Clue, Ovia). Or store it on a server and anonymise it somehow (Flo's Anonymous Mode routes through Cloudflare). Both trust the server. The server is the weak link. Encryption gets broken. Anonymisation gets reversed. Companies get acquired. Servers get subpoenaed. Servers get breached.

There is a third way. Do not have a server for your health data.

I picked the third way. An on-device period tracker where your cycle log, symptoms, notes, and predictions all live on the phone that made them, and never leave unless you export them yourself.

When I say "no server," here is exactly what I mean

The whole point of this piece is not hiding behind vague language. Specifically:

There is no server anywhere in the world that stores your period data. No cycle history. No symptom log. No intimacy notes. No predictions. Delete the app, the data goes with it. Switch phones, it goes with you or nowhere.

Bleed uses small server touches for two things. Neither sees your health data:

An anonymous session ID (a random UUID with no name, email, or device info attached) so I can send occasional messages from me to you. Just the mechanism.
Apple Pay via RevenueCat if you choose to tip. RevenueCat handles the payment flow. They see purchase events, not periods.

That is it. The distinction matters, and it will matter more as I tell you what "no server" cost me for the health data itself.

Tradeoff 1: No cross-device sync

Switch from iPhone to Android and you start over.

That is the part I hate telling people. Every other period tracker syncs across devices. You install Flo on your new phone, log in, and your entire cycle history is right there. Because it is on their server.

Bleed does not do this. Cannot do this. The whole point of a local data period tracker is that your data lives in exactly one place, and that place is the phone in your hand. If you buy a new phone, you have to export your Bleed data as a JSON file, transfer it however you like, and import it into the new device yourself.

Users hate this. I did not enjoy building it either.

But every solved version of cross-device sync in this space requires a server. The moment your cycle data sits on some cloud waiting for your other phone to ask for it, I have failed the promise. I would rather you lose sync than lose the architecture.

If a peer-to-peer, end-to-end encrypted sync ever exists that lets your devices talk without any Bleed server in the middle, I will build it. That version does not exist yet at a level I trust. Until it does, no sync.

Tradeoff 2: No cloud backup by default

Lose your phone and, unless you exported recently, your history is gone.

Bleed is a period tracker with no cloud sitting behind it. Users hate this. Competitor apps back up to iCloud, Google Drive, or their own cloud automatically. Phone drops in the ocean, five years of tracking are safe.

Bleed does not do that. If you want a backup, you open the app, hit export, save the file somewhere you trust. The responsibility is yours.

Here is the trade in one sentence. If a cloud backup exists automatically, a copy of your entire reproductive history exists on somebody else's server, and that server can be breached, acquired, or subpoenaed. Apple's iCloud is the least bad option in that category, and even Apple can be legally compelled. So I made the backup manual, in a format you control, on a schedule you set.

The upside: if Bleed gets hacked tomorrow, there is nothing to leak. The database of everybody else's cycle data does not exist. There is no dashboard for an attacker to breach.

Read that again. Most breaches in this industry are companies losing user data. Bleed cannot lose your cycle data because that database was never built in the first place.

Tradeoff 3: I cannot see your data to help you

When you email support at most period apps, the person on the other end can pull up your account, see your log, see your predictions, look at what is going wrong, and often fix it for you.

I cannot do that. Nobody at Bleed can. When you email us, we can see the exact thing you sent us and nothing else. If you ask "why did my prediction shift by three days," I have to guess with you. I ask you to describe what you see. I write back with likely explanations. If it does not match, we go again.

This is slower. Sometimes it is frustrating. It is also the entire point.

The support desk on a period tracker is a privileged view into millions of women's most personal data. That view has to exist for support to work. I decided it should not. When you write to me, you and I are on equal footing. You see your log. I see your email. That is all.

The wow moment: "wait, so nobody at Bleed can look at my data to help me?" No. That is the price of nobody at Bleed ever being able to look at your data.

Tradeoff 4: I can never take VC money

There is a standard playbook in health-tech startups. Acquire users. Collect their data. Monetize the data (ads, insurance partnerships, licensing to research consortia). Sustain the business on data revenue or sell to somebody who can. Investors expect this. They invest because this is the model.

Bleed cannot run that playbook. There is no cycle data on any Bleed server to monetize. If I wanted to pivot to ads tomorrow, I would need to first build the server, first collect the data, first betray the original promise. Every user here now would leave.

Bleed is uninvestable in the extractive VC sense. No data moat. No gated subscription. No premium tier to upsell. The model is: users tip what they think Bleed is worth, and that keeps the app running. If tips ever stop covering the small servers we do have, Bleed shuts down. It does not raise to survive. It does not switch to ads. It does not sell to Meta.

That is the survival commitment. A strong version of what Yuka does with food scanning. Yuka refuses ads, brand partnerships, and affiliate revenue because they would compromise their scores. Bleed refuses external capital because it would compromise the architecture.

The wow moment: this app cannot be sold out from under you, because there is nothing to sell.

The point

"We take privacy seriously" is what companies say when they don't. It costs them nothing to say and nothing to fail at.

What I did instead cost me sync. Cost me automatic backup. Cost me the ability to help you as fast as I would like to. Cost me the entire venture-backed startup playbook. Every one of those is a real thing that could have made Bleed easier to build, easier to grow, and easier to fund.

I took the harder path because it is the only path where I can look you in the eye and mean it when I say your cycle data is yours.

If you use Bleed, that is the deal we are in together.

Pass it on.