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).
The path to a live version that's fully GDPR-audited, with Amplitude + Customer.io wired perfectly
One sequence, combining both — they share the same first step. Ordered by dependency, not just priority.
1 — Ship the release You approve the push
The iOS branch carries consent gating, the severity-gate fix, both crisis-safety fixes, AND the Apple Sign-In email-capture fix — the last one matters for Customer.io specifically: 90% of known users currently have no email on file, so "wired perfectly" is blocked on this shipping, not on anything Customer.io-side. Deploy delete-user-data before or with this release (see the scale-audit wiki's sequencing item) — never after.
2 — The two 5-minute dashboard clicks You or Isabel
Segment Destination Filter on Amplitude (strips the email trait — makes Amplitude actually non-identifying, not just documented as such) and confirming Segment's actual plan tier (the single most urgent open item across every wiki tonight).
3 — Copy + design sign-off You + Isabel
Consent-screen visual design (still placeholder), the corrected Privacy Policy + Terms draft, the tone-of-voice findings — all drafted, none published. This is the one step that's genuinely both of your call, not engineering.
4 — The DPA checklist You, mechanical
Now actually written (DPA_CHECKLIST.md) — for most of the 8 processors this is "find the page, confirm it's accepted, save the record," not legal work. Anthropic is the one to actually chase down, since that relationship is newest.
5 — Two policy decisions You decide, Claude builds
Age-gate threshold (16 vs 18) and the data-retention window. Both small, both blocking a specific build once decided.
6 — Re-verify once real emails exist Claude, after step 1 ships
Once the Apple Sign-In fix is live and users actually have emails on file, re-check that Customer.io's 6 automations genuinely fire for them — the earlier "0 emails going out" finding was traced to this exact bug, so it should resolve itself, but it's worth confirming rather than assuming.
What's not on this list because it's already fine: Customer.io's EU-region setup, the delivery pipe itself (764/768 delivered in the last real check), and the erasure automation for Amplitude + Customer.io (built, tested, just needs the same deploy as step 1). Segment's own erasure leg is deliberately not on this list — see the delprop card below for why that's a reasonable thing to leave as-is, not a gap in "fully audited."
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. |