Why We Built Gliss Privacy-First: Encryption, Data Minimization, and Earning Trust
We could have built Gliss the easy way.
We could have embedded analytics SDKs from the start, the way nearly every app does. We could have collected location data, device fingerprints, and advertising identifiers alongside your cycle information. We could have written a long, vague privacy policy that technically disclosed all of this while making it nearly impossible for anyone to understand what it actually said.
That would have been the standard approach. It would have been faster to build, cheaper to operate, and easier to monetize. And for most app categories, it would have been fine.
But we are not building a weather app. We are building a space where people share the most intimate details of their physical and emotional health -- their cycles, their moods, their fertility, their losses, their bodies. And we decided very early that the standard approach was not good enough for that kind of trust.
This is the story of how we built Gliss privacy-first, what that actually means in practice, and why we think it matters more than any other feature we ship.
The Moment It Became Non-Negotiable
When we started designing Gliss, we studied the competitive landscape carefully. We looked at every major period-tracking app -- their features, their user experience, their business models, and their privacy practices.
What we found was not surprising, but it was clarifying. The dominant model in femtech is the same dominant model across consumer apps: offer a free product, embed third-party code that collects user data, and monetize that data through advertising or analytics partnerships. Privacy policies exist, but they are designed to protect the company legally, not to inform the user meaningfully.
The Flo Health situation crystallized something for us. Here was an app used by hundreds of millions of people, many of whom were sharing pregnancy status, miscarriage experiences, and fertility struggles. And that data was being transmitted to Facebook and Google through embedded SDKs, despite explicit promises of privacy. The FTC enforcement action and the subsequent class-action settlement confirmed what privacy advocates had been saying for years: the standard app business model is fundamentally incompatible with genuinely sensitive health data.
We did not want to be in a position where we had to explain to our users why their reproductive data ended up in the hands of an advertising network. So we made a decision: privacy would not be a feature we added later. It would be the foundation we built everything else on top of.
That decision made everything harder. And we would make it again without hesitation.
What "Privacy-First" Actually Means (Our Principles)
"Privacy-first" has become a marketing phrase. Every app claims to care about privacy. Few of them architect for it. We want to be specific about what it means for us, because specificity is the difference between a marketing claim and an engineering commitment.
Principle 1: End-to-End Encryption Is the Default
Your health data -- cycle dates, symptoms, moods, journal entries, AI companion conversations -- is encrypted on your device before it ever leaves your phone. We use end-to-end encryption, which means the data is encrypted with keys that only you control. Our servers store encrypted data that we cannot read.
This is not the same as "encryption in transit," which simply means data is encrypted while traveling between your phone and our servers (and which nearly every app does by default via HTTPS). End-to-end encryption means that even if our servers were compromised, even if we received a court order, even if a rogue employee tried to access your data -- they would get encrypted blobs that are meaningless without your keys.
We designed our system so that we cannot betray your trust even if we wanted to. That is not a policy. It is an architecture.
This creates real engineering challenges. Features that are trivial with server-readable data -- like server-side search, personalized push notifications, and data analytics -- require fundamentally different approaches when the server cannot read the data. We accepted those challenges because the alternative was unacceptable.
Principle 2: Data Minimization Is a Design Constraint
Data minimization means collecting only the data that is strictly necessary for the app to function, and retaining it only as long as needed.
In practice, this means:
- No location tracking. Gliss does not request location permissions. We do not know where you are, and we do not want to know.
- No device fingerprinting. We do not collect the unique identifiers that allow companies to track you across apps and websites.
- No advertising IDs. We do not integrate with advertising networks, so we have no use for the identifiers that power targeted advertising.
- No third-party analytics SDKs. We do not embed code from Google Analytics, Facebook, Mixpanel, Amplitude, or any other third-party analytics platform. Every piece of code in our app is code we wrote or open-source libraries we have audited.
- No unnecessary metadata. When you log a symptom, we store the symptom and the date. We do not store the time of day you logged it, how long you spent on the screen, what you looked at before and after, or any of the behavioral metadata that most apps collect automatically.
This is expensive in a different way than encryption. It means we have less data to work with when making product decisions. We cannot easily A/B test features by tracking user behavior in granular detail. We cannot identify drop-off points in our onboarding flow by watching where users hesitate. We have to find other ways to improve the product -- user research, direct feedback, opt-in surveys -- that respect privacy by default.
We think that trade-off is worth making.
Principle 3: Zero Data Selling, Sharing, or Monetization
This one is simple, but we want to be explicit because "we don't sell your data" has become one of the most misleading phrases in technology.
We do not sell your health data. We also do not share it, trade it, license it, or provide it to any third party for any purpose. Not to advertisers. Not to data brokers. Not to research institutions. Not to "trusted partners." Not to anyone.
The distinction matters because many companies that claim not to "sell" data still share it through partnerships, integrations, and analytics relationships that are functionally identical to selling. We close that loophole entirely. Your health data stays with you. Period.
Our business model is straightforward: you pay for the app through a subscription. That subscription funds our development, our infrastructure, and our team. We do not need to monetize your data because you are our customer, not our product.
Principle 4: You Control Your Data Completely
You can export all of your data at any time, in a standard format that you can take to another app or share with your healthcare provider.
You can delete all of your data at any time. When you delete your data, it is gone -- not archived, not retained for "a reasonable period," not kept in a backup that persists for years. Gone.
These are not just compliance checkboxes for GDPR and CCPA (though we comply with both). These are user rights that we believe should exist regardless of what the law requires.
Principle 5: Transparent, Readable Privacy Communication
Our privacy policy is written in plain language. Not legalese. Not corporate euphemism. Plain language that a person without a law degree can read and understand.
We also provide a visual summary -- a simple, honest overview of what data we collect, why we collect it, where it goes, and who can access it. This summary is accessible from within the app at any time, not buried in a settings menu behind three taps.
We believe that informed consent requires that the information actually be comprehensible. A 40-page privacy policy written in legal jargon is not informed consent. It is a liability shield disguised as transparency.
How Privacy Shapes the Product
Privacy-first is not just a backend decision. It shapes the user experience in ways that are visible every time you use the app.
The AI Companion
Our AI companion is one of Gliss's defining features -- a conversational partner that understands your cycle, recognizes patterns, and responds with warmth and intelligence. Building an AI companion with strong privacy is one of the hardest technical challenges we face.
Many AI systems work by sending your data to cloud servers, where it is processed by large language models. This approach is fast and powerful, but it means your most intimate conversations -- about your body, your emotions, your fears, your losses -- are being processed on servers you do not control.
We use a hybrid approach. As much processing as possible happens on your device. When cloud processing is necessary (because some AI tasks genuinely require it), your data is encrypted in transit, processed in isolated environments, and not retained after the response is generated. We do not use your conversations to train our models. We do not review them for quality assurance. We do not store them on our servers in readable form.
This means our AI companion may occasionally be slower or less capable than a system with full server-side access to your data. We accept that trade-off. Your conversation with your AI companion should feel as private as a conversation with a trusted friend. That requires architectural choices, not just promises.
Partner and Family Connect
The Connect feature lets you share cycle context with a partner, parent, or family member. This is one of the features we are most proud of -- and one where privacy is most critical.
Sharing is entirely user-controlled. You decide what to share (phase information, general mood context, detailed symptoms, or nothing at all), and you can revoke sharing at any time with a single tap. Connected people see a curated, limited view -- never your raw data, never your journal entries, never your companion conversations.
We built Connect with an explicit awareness that sharing intimate health data within a relationship is not always a free choice. Controlling partners could pressure someone to share. Family dynamics can be coercive. That is why every sharing invitation includes a clear reminder that sharing is voluntary, and why we designed the revocation process to be instant and invisible to the connected person.
Onboarding
Even our onboarding process reflects privacy-first thinking. We ask you what brings you to Gliss -- not because we want to build a marketing profile of you, but because we want to avoid showing you content that could be triggering.
If you tell us during onboarding that you have experienced pregnancy loss, we will never show you pregnancy-related content unless you ask for it. This is the opposite of how most apps use onboarding data (to optimize conversion funnels and target marketing). We use it to protect you.
Every onboarding question is skippable. You can use Gliss without telling us anything about yourself beyond basic cycle information. The app works. It just gets more personalized as you choose to share more.
The Hard Parts (What Privacy-First Costs)
We want to be honest about what privacy-first architecture costs, because pretending it is free would be dishonest.
Engineering Complexity
End-to-end encryption adds significant complexity to every feature we build. Features that take a team a week with server-readable data can take a month with E2E encryption. Key management, data synchronization across devices, and encrypted search are genuinely hard problems.
Product Analytics Limitations
Without third-party analytics, we have less visibility into how people use our app. We cannot easily see which features are popular, where users get confused, or how our onboarding flow performs. We rely more heavily on direct user feedback, which is higher quality but lower volume.
AI Capability Constraints
Our privacy-preserving approach to AI means our companion cannot access as much data as easily as a system that processes everything server-side. We work around this through careful architecture, but there are real trade-offs in speed and capability.
Business Model Discipline
Without data monetization as a revenue stream, we depend entirely on subscription revenue. This means we need to build a product that is good enough for people to pay for. There is no safety net of advertising revenue to fall back on. We think this is actually a good thing -- it aligns our incentives with our users' interests -- but it requires financial discipline.
Competitive Perception
Some users will compare Gliss to free apps and wonder why they should pay. The answer is that free apps pay for themselves with your data. But that answer requires education, and education requires trust, and trust requires time.
Our Stance on Law Enforcement
We want to be direct about this because it is one of the most important questions in reproductive health technology right now.
Gliss will not voluntarily share user data with law enforcement. If we receive a legal request (a subpoena, a court order, a warrant), we will evaluate it carefully with legal counsel. We will challenge requests that we believe are overbroad, unconstitutional, or designed to target reproductive health decisions.
And because of our end-to-end encryption architecture, even if we were compelled to produce data, what we could produce would be encrypted information that we cannot read. This is not a policy position that could change with new leadership or new legal pressure. It is an architectural reality that is baked into our system design.
We believe this is the responsible approach. We cannot predict how reproductive privacy law will evolve in the coming years. We can design a system where the question of whether we would share your data is largely moot, because we do not have the ability to read it.
How to Hold Us Accountable
Promises are cheap. Architecture is harder to fake, but still requires trust. Here is how we intend to earn and maintain that trust over time.
Independent Security Audits
We are committed to regular third-party security audits of our infrastructure and our encryption implementation. When these audits are complete, we will publish the results -- including any issues found and how we addressed them.
Open-Source Components
Where possible, we open-source the privacy-critical components of our infrastructure. Open-source code can be inspected by anyone -- security researchers, journalists, privacy advocates, and our own users. This is the highest form of transparency: not telling you how our privacy works, but showing you.
Canary Statements
We will maintain a transparency report and warrant canary that discloses, to the extent legally permitted, any government data requests we receive. If the canary disappears, that itself is a signal.
Ongoing Communication
When we make changes to our privacy practices, our data handling, or our infrastructure, we will communicate those changes clearly and in advance. Not in a changelog buried in an app update, but in direct, human-readable communication.
Why This Matters Beyond Gliss
We are not writing this piece to convince you to use Gliss. We are writing it because we believe the entire reproductive health technology industry needs to do better on privacy.
The current standard -- free apps monetized through data sharing, with long and unreadable privacy policies that technically disclose bad practices while making them impossible to understand -- is not good enough. Not for period-tracking apps. Not for fertility apps. Not for pregnancy apps. Not for any app that handles data this sensitive.
The post-Dobbs legal landscape made the stakes obvious, but the problem existed long before that decision. Reproductive health data has always been intimate, always been sensitive, and always deserved better protection than it received.
We hope that by being transparent about our own approach -- including its costs and limitations -- we can contribute to a broader conversation about what privacy-first health technology should look like. We hope other companies in this space will adopt similar architectures, not because we benefit from it, but because users deserve it.
If you are building a health app of any kind, we encourage you to start with the same question we did: "What is the minimum data we need, and how do we protect it from everyone, including ourselves?"
The answer will make everything harder. And it will make everything better.
The Gliss Privacy Promise, in Plain Language
We will close with the simplest version of what we believe and what we commit to:
What we collect: Only the health data you choose to share with the app, and the minimum technical data needed to keep the app working.
What we do with it: Help you understand your body. That is it.
Who sees it: You. Anyone you explicitly choose to share with through Connect. No one else.
What we do not do: Sell it. Share it. Monetize it. Give it to advertisers. Embed tracking code. Fingerprint your device. Track your location. Build a profile on you. Any of it. Ever.
What happens when you leave: You can take your data with you. You can delete it permanently. When it is gone, it is gone.
This is not a feature. This is who we are. And if we ever fail to live up to it, we expect you to hold us accountable.
Your rhythm. Your data. Your control.