The Flo settlement
In 2021, the Federal Trade Commission settled with Flo Health, the maker of the Flo period tracking app, over allegations that the company had shared users' menstrual health data with third parties including Facebook and Google despite explicitly promising not to. The data shared included information about whether users were trying to get pregnant, had recently had a miscarriage, or were experiencing other reproductive health events. Flo had over 100 million users at the time.
The 2021 FTC settlement required Flo to notify affected users and obtain independent privacy audits. It did not include a financial penalty. In 2025, a class-action lawsuit resulted in a $56 million settlement — one of the largest privacy settlements involving a health app to date. The underlying conduct that prompted both actions was not a breach or a hack. It was the ordinary operation of a business model built on data collection and sharing.
Flo is not an outlier. The period tracking app market has historically been built on the same advertising and data-broker infrastructure as the broader consumer app ecosystem. The data collected — cycle dates, symptom logs, notes about reproductive health decisions — is unusually sensitive, but the monetization approach has been standard.
The post-Roe legal landscape
Following the Supreme Court's 2022 decision in Dobbs v. Jackson Women's Health Organization, which overturned Roe v. Wade, reproductive health data took on a new dimension of legal risk in the United States. Several states enacted laws restricting or criminalizing abortion, and in some cases, digital records have been sought in legal proceedings related to reproductive health.
Period tracking data — specifically, records of missed periods, cycle irregularities, or notes about reproductive decisions — could theoretically be relevant in such proceedings. Law enforcement agencies can subpoena data from app companies, and companies that store user data on their servers are obligated to respond to valid legal process. A company that has no data cannot produce what it does not have.
This is not a hypothetical concern for users in states with restrictive laws. It is a concrete reason why the architectural choice of where data is stored — on the user's device versus on a company's servers — has real-world consequences beyond convenience or preference.
What "privacy-first" should actually mean
The phrase "privacy-first" has become common enough in app marketing to be nearly meaningless. Evaluating a period app's privacy claims requires looking past the marketing language to the actual architecture and data practices.
A genuinely privacy-first period tracker should meet all of the following criteria:
- No user accounts. If the app requires you to create an account, your data is linked to an identity the company controls. Account creation is the first step toward a server-side data store.
- No analytics or telemetry. Analytics SDKs (including "privacy-respecting" ones) report usage data back to servers. A privacy-first app has none.
- No third-party SDKs beyond payment processing. Every third-party SDK is a potential data pipeline. The fewer, the better. Payment processing (for in-app purchases) is a narrow, justified exception if the SDK receives only anonymous identifiers and purchase receipts — not health data.
- No servers storing your data. If the company has your data, it can be subpoenaed, breached, or sold. The only way to guarantee data is not on a server is to never put it there.
- On-device encryption. Local storage alone is not enough if the data is stored in plaintext. Sensitive fields should be encrypted with a key that lives in the device's hardware-backed secure store.
Most apps that describe themselves as privacy-first fail at least one of these tests. Some have no analytics but require accounts. Some store data locally but in plaintext. Some use "privacy-respecting" analytics that still report to external servers. The checklist above is a useful filter.
How to evaluate a period tracker's privacy claims
Before trusting an app with this data, a few concrete steps are worth taking:
- Read the privacy policy. Look specifically for what data is collected, where it is stored, who it is shared with, and under what conditions. Vague language like "we may share data with trusted partners" is a red flag.
- Search the company in FTC filings. The FTC's public database of enforcement actions and settlements is searchable. If a company has been the subject of an FTC action related to privacy, that is material information.
- Check the App Store privacy nutrition label. Apple's App Store shows a "Privacy Nutrition Label" for every app, listing what data the app collects and whether it is linked to your identity. This is self-reported by developers, but it is a useful starting point.
- Look for signs of marketing-list collection. If the app asks for your email address, offers a newsletter, or has a referral program, it is building a marketing list. That list is a data asset with its own value and its own risks.
Why Vellum took the harder path
Building a period tracker with no server infrastructure is genuinely harder than building one with a backend. There is no cross-device sync, because sync requires a server. There is no cloud backup, because backup requires storage. There are no "smart" AI-powered insights that improve with aggregated user data, because aggregation requires collection.
Each of these is a real trade-off. Some users will want cross-device sync and will choose a different app. That is a reasonable choice. Vellum is for users who have decided that the privacy trade-off is not worth it — that the convenience of cloud sync is not worth the risk of their reproductive health data living on someone else's server.
The architectural decisions were made at the start of the project, not bolted on afterward. There is no server to subpoena, no database to breach, no marketing list to sell, and no analytics pipeline to audit. The privacy promise is not a policy that can be changed in a future update — it is a consequence of how the app is built.