Do I Need to Let Users Delete Their Account and All Their Data?
6 min read
Yes, in most cases you do need to let users delete their account and the data you hold about them. If you have users in the EU or UK, the right to erasure under GDPR makes it a legal obligation, and California's CCPA gives similar rights. Even where no law applies, app stores and payment providers expect it, and a user who asks and gets ignored is the one who leaves a public complaint.
Why this happens
Your AI agent built a sign-up flow because you asked for one. Nobody asked for the reverse. Deletion is the feature that never shows up in a demo, so it never gets built. The result is an app that can take a user in but has no way to let them out, and a database that only ever grows.
There is a second, quieter problem. Even where a "delete account" button exists,
vibe-coded versions often just flip a flag or remove one row from a users
table. The profile, the uploads, the messages, the Stripe customer, and the rows
in five other tables all stay behind. The account looks gone; the data isn't.
How to check
- Log in as a test user and look for the option. Is there a "Delete account" control anywhere in settings? If not, you have no deletion path at all.
- If a button exists, follow the data. Delete a test account, then open
your database and search every table for that user's
id, email, and name. Anything that comes back is data you claimed to erase and didn't. - List where user data actually lives. It is rarely one table. Check your auth provider (Supabase Auth, Firebase, Clerk), your storage buckets for uploaded files, your payment provider for the customer record, and any logs or analytics that carry personal fields. If you are unsure what you store, start with what user data your app is actually storing.
The fix
- Add a clear deletion control in account settings, behind a confirmation step so nobody triggers it by accident.
- Delete across every store, not just one table. Remove the auth record, the profile and related rows, uploaded files in storage, and the customer object at Stripe or your payment provider. On Supabase, deleting the auth user should cascade to your tables only if you set the foreign keys up that way, so verify it rather than assuming.
- Decide what you are legally allowed to keep, and say so. You can retain a minimal record for a real reason, for example an invoice you must keep for tax law, or a suppression entry so a deleted user is not re-imported. Keep the minimum, document why, and delete the rest.
- Confirm and log the deletion. Show the user it is done, and keep a small, non-identifying record that the request was honoured and when.
- Re-run the search from the check step. A deletion you cannot verify is not
a deletion. The user's
id, email, and name should return nothing.
The trap to avoid
Do not "soft delete" and call it done. Setting is_deleted = true while the
name, email, and uploads sit untouched in the database is not erasure, it is
hiding the row from your own screens. Under GDPR that still counts as data you
hold, and a regulator or a curious user will not be impressed that it was flagged
rather than removed. Soft delete is a fine internal pattern, but it must be
followed by real deletion of personal data within a defined window.
Where this fits
Deletion is one of the data rights real users exercise in the first weeks, and it is almost always missing or half-built in a vibe-coded app. The free Readiness Report checks whether you have a deletion path and whether it actually clears every store, so you find the gap before a user does. The Finishing Pass hands you the fixes in order. Deletion's twin is the data export feature users have an equal right to, and both get easier once you know which of your fields count as personal data.