FemTech Product Engineering: Building Where the Data Is the Risk
Cycle, fertility and maternal health products hold some of the most sensitive data any consumer app collects. That single fact should drive the architecture (retention, inference, export and deletion) long before it drives the privacy policy.
Most consumer products treat their data model as an implementation detail and their privacy posture as a document produced near launch. FemTech cannot work that way. A cycle-tracking, fertility or maternal health product holds information that is sensitive in a categorically different way to an email address: it reveals health status, it can reveal pregnancy before the user has told anyone, and in some jurisdictions it carries legal exposure for the person it describes. The data is the risk, and the architecture is the only place that risk is genuinely managed.
This has an unusual consequence for product engineering. In most categories, collecting more data is a default good: it improves personalisation, it feeds the model, it is available later for questions nobody has asked yet. In FemTech, every field collected is a liability that has to earn its place, and the discipline of declining to store something is a product decision with real value.
Four decisions that set everything else
- Retention. How long is each category of data kept, and what deletes it? A retention policy that exists only in a document is not a policy; it is an intention. It should be a scheduled job with a test.
- Inference. What does the product derive that the user did not enter? A predicted cycle date is inferred health data, and it is often more sensitive than the entries that produced it. It needs the same protection as input data, and users are frequently surprised it exists at all.
- Export and sharing. Partner sharing, clinician access and data export are genuinely useful and each one creates a copy outside your control. They need to be revocable, scoped, and visible to the user in a list they can act on.
- Deletion. What happens when someone deletes their account? If derived data, backups, analytics events and third-party copies survive, the product has not deleted anything: it has hidden the record from one interface.
Consent has to be enforceable, not recorded
A consent flag stored on a user row that nothing checks is theatre. Consent is real when the data access path itself is gated on it: when a query for shareable data cannot return unshared records because the boundary is in the code rather than in the caller's discipline. That is testable, and it survives the next developer who does not know the rules.
Where AI fits, and where it should be kept out
There are genuinely useful AI applications in this category. Making a long symptom history searchable in plain language. Surfacing a pattern a user might want to raise with a clinician. Reducing the friction of logging so the record is complete enough to be worth anything. Content that adapts to where someone is in a journey rather than presenting the same library to everyone.
What warrants far more caution is anything that reads as a clinical conclusion. There is a meaningful difference between surfacing that a pattern has changed and telling someone what that change means, and products drift across that line through wording rather than through a decision anyone made. It is worth writing down, early, which side of that line the product sits on, and then checking the copy against it, because the engineering can be impeccable and the drift will happen in a microcopy review.
Analytics is where discipline usually leaks
A team can be careful with its primary data model and still leak through instrumentation. Event names that encode health state, screen names that reveal why a user is in a flow, crash reports carrying payloads, session recording tools that capture inputs by default: each is a copy of sensitive data leaving for a third party, added by someone solving an unrelated problem.
The practical control is an allowlist rather than a blocklist: instrumentation sends the events it has been explicitly permitted to send, and adding a new one requires a deliberate change. This is slightly more friction than most teams want, and it is the difference between a privacy posture that holds and one that was true on the day it was reviewed.
Trust is a retention feature
The commercial argument and the ethical one converge here, which is not always true. Users of these products are unusually aware of what they are handing over and unusually quick to leave when something feels wrong. Clear data controls, visible deletion, honest language about what is inferred, and the absence of unexpected sharing are not compliance overhead; they are the reasons someone keeps logging, and a product of this kind is worth very little without a complete record.
In FemTech, the strongest privacy decision is usually the field you decided not to collect. Everything after that is mitigation.
For founders and product leads
Ask a prospective engineering partner what happens to derived data on account deletion, and whether consent is enforced at the query layer or checked by convention. Both questions are answerable in a sentence by anyone who has built in this category, and both expose quickly whether privacy is part of the architecture or a document someone will write before launch.