Privacy by Design: How We Think About Your Data

A journal entry, a mood score at 2am, a note about what a therapist said in a session — this is about as sensitive as personal data gets, and most of the industry's answer to that sensitivity is a privacy policy written by lawyers for other lawyers. We wanted YouMindo's approach to privacy to be something a user could actually interact with, not just read about once during signup and never see again.

That meant building privacy features the same way we build anything else on the roadmap — with a spec, a design review, and a real place in the product where you can actually use them, not a clause buried in a document. Two of those features, data export and deletion, took longer to build than we initially budgeted, because doing them properly meant touching nearly every table in our system, and we think that time was worth it.

Export and deletion as real features, not tickets

Before we built self-service export and deletion, exercising either right meant emailing support and waiting for a manual process on our end — technically compliant with most privacy regulation, practically a barrier most people wouldn't bother clearing. We rebuilt both as features reachable in three taps from account settings: export produces a complete, structured download of everything tied to your account, and deletion actually removes it, not just flags it inactive.

What 'deleted' actually means

We debated, at length, whether deletion should be immediate or delayed with a recovery window. We landed on a short grace period — deletion is scheduled, confirmed by email, and reversible for a brief window in case of a mistaken tap, then executes permanently. After that window, the data is actually gone from primary storage, not soft-deleted and quietly retained, which required real engineering work across every table that touched a user's data, not a single flag we could flip.

The line we drew on journal content

Journal entries are never used for advertising, sold to third parties, or fed into model training without a separate, explicit opt-in beyond basic account consent. We enforce this at the schema level — the tables and access patterns that touch journal content are isolated from the systems that could plausibly repurpose it, so the boundary isn't just a policy someone has to remember to follow, it's a constraint the infrastructure makes harder to violate by accident.

What therapists can see, and what they can't

A therapist on the platform doesn't get a data firehose about their client by default. Mood history, completed exercises, and journal entries are each individually toggleable by the client, off by default for journal content specifically, and changeable at any time. We built this as granular controls rather than one sharing switch because clients told us, consistently, that they wanted to share some things with their therapist and keep others private — a nuance an all-or-nothing toggle can't represent.

The debate about analytics

Our product team wanted usage analytics granular enough to understand exactly which exercises helped and which didn't — reasonable, and useful for improving the product. Our clinical advisors pushed for analytics to be aggregated and anonymized wherever it touched anything clinically sensitive, even at the cost of some product insight. We landed closer to the clinical side: individual-level analytics on things like button clicks and screen time, but no individual-level analytics tied to the content of what someone wrote or how they scored on an assessment.

The mistake: an early build asked for too much

Our original onboarding flow asked for optional fields — income bracket, relationship status, employment status — that we thought might help personalize the experience. None of it was required, all of it was disclosed, and none of it was misused. We removed most of it anyway once we looked honestly at whether we actually needed it to deliver the product, versus whether it was just data we thought might be useful someday. 'We might use this eventually' is not a good enough reason to collect sensitive data now.

Where we've said no to integrations

We've turned down partnership and integration proposals that would have required sharing user data with third-party analytics or marketing platforms, even in aggregated form, when the value to users was unclear and the value to us was mostly commercial. Not every one of these was an easy call — some would have genuinely improved parts of the product. But the default answer to 'can we share this to enable X' has to be no, with the burden of proof on the exception, not the other way around.

What encryption does and doesn't solve

We encrypt data in transit and at rest, which is table stakes and not something we consider a distinguishing feature. What encryption doesn't solve is who has access once data is decrypted for legitimate use — a therapist reviewing session prep, an admin investigating a safety flag, an engineer debugging a production issue. Our access controls and audit logging around that decrypted access matter at least as much as the encryption itself, and get far less attention in most conversations about data security.

The limits of a privacy policy

We still have a privacy policy, because we're required to, and we've tried to write it in language a person could actually parse rather than pure legal boilerplate. But we don't think a policy document is where privacy actually lives in a product. It lives in whether the delete button in settings really deletes something, whether a toggle really turns a data flow off, and whether the default settings we ship favor the user or favor us. We'd rather be judged on those than on the document.

None of this makes YouMindo immune to the kinds of failures that happen anywhere data is stored — no honest company can promise that. What we can promise is that we've tried to build the defaults, the controls, and the deletion path as if we'd have to explain every one of them to a user who asked, in person, exactly what happens to what they write. That standard has shaped more of this product than any compliance requirement did.