Privacy by designwhat we do (and don't) with your data

Why I care about this more than most features

I'm Serhii Rohachov, a Kyiv-based product designer and developer. I designed and built Mommy Refuel end to end, and I also run seven a.m., an AI-native product and business-systems holding that Mommy Refuel is part of, alongside WiZMe. None of that background is what makes privacy matter here — the subject matter does. This app exists to hold check-ins about your mood, your sleep, your recovery after birth, symptoms you're worried about, and sometimes a note you wouldn't say out loud to anyone else.

That is not the kind of data you get to be casual about. So before I wrote a single onboarding screen, I wrote down what the app is not allowed to do: no advertising SDKs, no selling wellbeing data, no third-party analytics, and no dumping your private notes into a general AI context just because it would be convenient to build. Those constraints are still true today, and this post is me explaining them plainly instead of burying them in a privacy policy nobody reads.

Local-first: your data starts, and mostly stays, on your phone

By default, Mommy Refuel is a local-first app. Your check-ins, recovery entries, journal, priorities and profile are stored on your device with file protection, and the more sensitive free text — private notes, recovery notes, journal entries — sits in an encrypted local store rather than a plain file. If you're using the app as a guest, nothing is stored off your device at all.

If you choose to enable cloud sync (so your data survives a lost phone or follows you to a new one), your data moves to a backend with row-level security, meaning the database itself enforces that only you can read or write your own rows — it isn't just an app-side promise. Encrypted fields stay encrypted at rest there too. Sync is opt-in, not a default you have to notice and turn off.

Analytics that can't leak what you actually felt

Most apps' analytics systems are a junk drawer: someone adds "track this event with this payload" and six months later the payload quietly includes a mood score or a symptom name. I didn't want that to be possible by accident, so the rule is structural rather than a policy: analytics events come from a fixed, compile-time allow-list of event names with no sensitive fields — things like "a check-in was started" or "a help request was shared" — and there is a guard that drops anything that looks like a health value or free text before it can ever be sent, flagging it in development so it gets caught, not shipped.

Concretely, we can see that you completed a check-in. We cannot see your mood, energy or sleep values, your symptom type or severity, your Refuel Score, or a single word of anything you wrote. And analytics itself is off until you explicitly opt in — there is no third-party analytics or advertising SDK in the app at all.

AI: off by default, named when it's on, minimized always

The app has to work fully with AI turned off — that was a hard requirement, not a fallback state, because a wellbeing app shouldn't hold your ability to see your own patterns hostage to an AI subscription or an API being up. When you do turn Refuel AI on, you're shown, in plain terms, which provider processes the request — we don't hide it behind marketing language like "smart insights." That naming is a consent-gate decision, not a footnote: you should know whose model is reading your context before you agree to send anything.

What actually gets sent is deliberately thin. Each AI task — explaining your score, drafting a help message, summarizing your week — has its own allow-list of exactly which structured fields it may use, and the backend rejects anything outside that list. Your private check-in note and your recovery and journal notes are excluded by default and never enter that context; if a future task genuinely needed a note, it would require its own explicit consent for that action, not a blanket one. There are no names or emails in the payload — the backend already knows who you are from your login, so it doesn't need your identity repeated in the text an AI model sees.

What we deliberately do not do

A few lines I'd rather state outright than leave implied:

• We do not train models on your data. Raw journal text and raw maternal-health data are never used to build a training dataset, casually or otherwise — if personalization ever needs machine learning in the future, the plan requires privacy-minimized, pseudonymized or aggregated features first, and a validated case for why a deterministic approach isn't enough.
• Care recipients see only what you send them. If you share a help request with a partner or friend, they see the message — never your scores, notes or logs.
• A doctor summary only includes what you chose. Every line has its own toggle before anything is shared, and booking a specialist never auto-shares your summary behind your back.
• No advertising, no selling. There is no ad SDK in this app, and wellbeing or health data is never sold, full stop.

Delete Everything actually deletes everything

You can delete your account and your data from inside the app — Profile → Delete account — without contacting support or filling out a form. It's built to purge your local store and, once your data is synced, to hard-delete the server-side copy too, not just mark it inactive. If you're a guest, deletion clears your local store the same way.

You can also export your data before you go, so deleting isn't a choice between keeping a copy and having privacy. Both should be available at once, in your own hands, whenever you decide.

The honest version, one more time

None of this makes Mommy Refuel special for its own sake — it makes it match what I think an app that touches maternal health should have to do as a baseline, not a selling point. If you ever read something in the app that seems to contradict what's written here, that's a bug worth reporting, not a technicality to explain away. You can read more about how the AI layer and the safety layer relate to each other in Trust & safety, and see what's stored where in Journal & insights.