nothing here touches a live user until you approve it.
Making Allin airtight on privacy — the plan, in plain language
Allin holds people's most private material: how they feel, the beliefs underneath, memories, free-text reflections. This is a map of everything I'd do to protect it and meet the law — what each change is, why, exactly what happens, and how it touches the people already using the app. You approve, hold, or reject each one. I only act on the ones you approve.
How this works — and the one rule
The rule: the app is live and people are entering real data right now, so I will not apply anything to the production database, change anything users see, or ship any build without your explicit yes. This page is where you give (or withhold) that yes, item by item.
Every card has a What / Why / Exactly what I'd do, plus two things you specifically asked to see: how it affects current users and how it affects the experience. Each also carries a risk level and who does it. Tap a card to open it, then choose Approve · Hold · Reject. When you're ready, hit Copy my decisions and paste them to me — I'll work through only the approved ones.
Safe
Documents or code on a branch. Touches no live user and no prod data. I can just do these.
Low
Small, additive, reversible. Real but contained — e.g. adding a view to the database.
Medium
User-facing or needs a release. People will notice; needs your copy sign-off + an app update.
High
Touches the live data model while users are writing. Only via a backup + staging copy + careful cutover, with you approving each step.
You're a mental-health-adjacent product running paid ads
Three facts stack up: you process special-category health data (Article 9 — mental/emotional data), you're acquiring users with paid ads (so volume is climbing), and you're a UK company serving several countries. That combination raises the bar from "good hygiene" to specific legal duties: explicit consent for the health data, a DPIA, an age-appropriate design (the UK Children's Code applies to any service children are likely to reach — you have no age gate today), honest marketing claims, and a documented lawful basis for sending data to US processors.
Good news you should hold onto: your crisis support is genuinely strong (region-aware hotlines, tap-to-call — verified in the code), and account deletion already fully erases the database (verified: every table cascades). So this isn't a rescue job. It's closing specific, known gaps before the numbers get bigger.
"Can you — or Isabel, or I — tie a private note to a real name?"
Right now: yes, trivially, and you were right to be uneasy. The notes live in tables keyed by the account's user id, and the account's email sits in the auth table, so anyone with database dashboard access can join a reflection to an email in a single query. That includes you, Isabel, and — because I currently reach the database through a privileged connection — me. That's exactly what happened when you saw names next to data.
Fixing it honestly takes two layers, and it matters that you understand the difference, because the first one alone is not enough:
Layer 1 — Redacted views Low
A "read-only window" that shows only a truncated id (e.g. a1b2c3d4) and coarse metadata — never the note text, never an email. Limit: it only protects you when you log in through a special low-privilege account. It does not stop the database owner login — or my current connection — from bypassing it. Useful, fast, but discipline-based.
Layer 2 — Separate + encrypt High
Give each user a random pseudonym so the notes tables never contain the account id, and encrypt the note text so the database stores unreadable ciphertext. Then even a full-privilege login — you, me, anyone — sees a random token next to gibberish. This is what actually makes it impossible to tie sensitive text to a person.
My honest recommendation: do Layer 1 now (it's quick and I'll switch myself to the restricted account immediately), and schedule Layer 2 carefully — it changes how the live app reads and writes data, so it must be staged with a backup, not rushed. Both are cards below (#7, #8, #15, #16).
What actually touches the people already using Allin
Most of this is invisible to current users. Here's the honest split so you can see where the real-world impact is concentrated.
| Change | Do current users notice? | What they'd experience |
|---|---|---|
| All Phase-0 items | No | Nothing — documents + code sitting on a branch until you ship. |
| Redacted views (Layer 1) | No | Invisible — it only changes what admins can see, not the app. |
| Onboarding + consent rebuild | Yes, on next update | A clearer, consent-first first-run: age step, granular choices, explicit "okay to save your reflections?". Existing users see the new consent once. |
| Pseudonym + encryption (Layer 2) | No, if done right | Nothing visible — but done carelessly it could disrupt saving/loading, which is why it needs staging + backups. |
| Retention / auto-purge | Depends on your policy | A conservative policy touches almost no one; we'd never auto-delete active users' recent reflections. |
| Deletion → processors · data export | Only if they use it | Better erasure + a "download my data" option for anyone who wants it. |