I Built a Period Tracker That Technically Cannot Sell Your Data — Here's How

As software developers, we are taught to default to the cloud.

When you start a new mobile app project, the playbook is virtually identical: spin up a backend database, configure a cloud storage bucket, integrate a popular authentication provider, and drop in a couple of analytics SDKs so you can measure user behavior.

But in 2025, after watching the legal and regulatory fallout surrounding menstrual tracking apps, I realized that for certain types of software, this standard playbook is a structural liability.

Flo Health settled a $59.5 million combined proposed class action and FTC dispute over claims that it shared users' private health logs with Facebook and Google via analytics SDKs. Similarly, in 2022, Stardust marketed itself as the first end-to-end encrypted (E2EE) period tracker. However, security audits quickly revealed that their database architecture was sending plaintext encryption keys back to their servers, while their app was leaking user phone numbers directly to Mixpanel's analytics SDK. Worse, their original privacy policy stated they would voluntarily share data with law enforcement "whether or not legally required" (a clause removed only after intense public backlash). In the post-Dobbs landscape in the United States, prosecutors can subpoena corporate databases to obtain menstrual cycle logs as evidence.

When users ask, "Is my period data safe?" most companies point to their privacy policy. They promise they won't sell your data, or they promise they keep it secure.

But as developers, we know a basic truth: A policy is just a promise, and promises can be broken, acquired, or subpoenaed. The only data that is truly secure is the data you never collect.

So, I decided to build a period tracker that technically cannot sell your data because it holds none. The app is called Luna. Here is the technical breakdown of how we built it, the architectural trade-offs we made, and why we opted out of the cloud completely.

1. The Local Database: Replacing the Cloud with Drift & SQLite

In a standard architecture, when a user logs a cycle event, the app fires an HTTP POST request to an API endpoint, which writes the data to a relational database (like PostgreSQL) running in the cloud.

For Luna, we decided that all user data must reside exclusively on the physical device.

We built Luna using Flutter, and for storage, we chose Drift (formerly Moor), a reactive persistence library for Dart built on top of SQLite.

When you log a cycle start date, flow intensity, or daily symptoms in Luna, the write operation is performed locally on the device in milliseconds. There are no API keys, no remote hostnames, and no network requests.

If the user uninstalls the app, the SQLite database file is wiped from the device's storage partition by the operating system. Because we never had a remote copy, the data ceases to exist entirely.

2. Eliminating the Third-Party SDK Bloat

If you run a network proxy tool like Charles or Proxyman while using most mainstream apps, you will see a constant stream of outgoing traffic to third-party endpoints.

Many developers include these SDKs without a second thought:

• Firebase Analytics / Google Analytics: To track user journeys and funnel conversions.
• Mixpanel / Amplitude: To run cohort analyses.
• Sentry / Crashlytics: To catch runtime exceptions.
• Facebook SDK: To attribute app installs from social media ads.

But these SDKs don't just send anonymous button clicks. They collect device identifiers, IP addresses, screen names, and sometimes custom event parameters containing health inputs. In the Flo FTC complaint, it was precisely the custom parameters sent to Facebook's SDK that leaked users' pregnancy and cycle status.

Our architectural rule for Luna was simple: Zero third-party analytics and tracking SDKs.

We do not use Firebase Analytics, Mixpanel, Amplitude, or Adjust. We do not use Sentry. For crash reporting, we rely on local error logging that is stored on-device and can be optionally exported by the user if they request support.

This means we operate in complete dark: we don't know how many active users we have on a given Tuesday, which buttons are clicked most, or what screen has the highest drop-off rate. As a product developer, this makes optimization incredibly difficult. But as a privacy advocate, it is the only way to guarantee that device data isn't leaking to ad networks.

3. On-Device Computation: The CycleEngine

Predicting a user's next period, fertile window, and ovulation day is usually handled by a backend service. A server reads the historical cycles, runs the prediction engine, and returns a JSON payload to the client.

For Luna, we moved the entire prediction engine—written in Dart and called CycleEngine—directly into the client package.

Every computation runs locally in under 5 milliseconds. No round-trips, no servers, and no latency.

4. Resolving the Backup Problem with Client-Side Encryption

One major challenge of local-only storage is data loss. If a user drops their phone in the ocean, their entire cycle history is gone. In a cloud-sync app, they simply log back in on a new device.

To solve this without creating a central server, we implemented manual client-side AES-256 encryption.

Users can generate an export file (with a .lbk extension) directly within the settings screen. The app prompts the user for a password, derives a key using PBKDF2, and encrypts the raw JSON payload with AES-256-CBC.

The resulting file is fully encrypted. The user can save it to their local downloads folder, send it to their computer, or write it to a physical flash drive. If they get a new phone, they import the .lbk file, enter their password, and decrypt the database locally.

At no point does the unencrypted data, the encrypted file, or the password touch a server owned by us.

The Hard Architectural Trade-offs

I want to be realistic about the trade-offs of this approach. Building an offline-first, no-account app means giving up features that are standard in modern apps:

1. No Multi-Device Sync: You cannot view your cycle on your tablet and your phone simultaneously unless you manually export and import a backup.
2. No Web App Version: Because data resides in the mobile operating system's SQLite store, there is no easy way to build a web portal without sync backend synchronization.
3. Blind Product Decisions: We cannot track user retention cohorts or run A/B tests on button layouts. Every design change must be guided by qualitative feedback rather than click metrics.
4. Billing Complexity: Validating in-app purchases (Luna Plus) without user accounts requires processing receipt tokens directly with the Google Play billing API, using local verification mechanisms where possible.

Shifting the Paradigm

The tech industry has spent a decade collecting as much user data as possible under the assumption that "more data equals more value."

But in categories as intimate as reproductive health, data is no longer just an asset—it is a liability.

Luna is an experiment in showing that you can build a premium, highly responsive health companion without compromising architectural integrity. If a court ever serves us a subpoena for cycle logs, our legal response is incredibly simple: We don't have it.

Luna is open-source-first and built entirely in Flutter. Check out the project at luna.rahatlabs.com or download it directly from Google Play.

Frequently Asked Questions (FAQ)