Data export and account deletion that really work

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Data export and account deletion that really work

Users of the production site should be able to get a copy of their data and delete their account without emailing anyone, and the deletion should reach every place their data lives. Privacy laws give many users this right, app stores require deletion, and it is a strong trust signal at launch.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Delete any real user's data while testing.
- Delete records the law requires keeping.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Find every place user data lives

From the schema and code, list every table, column, file store, search index, cache and third-party service (email, analytics, payments, CRM) that holds data tied to a user. Mark which rows are personal, which must be kept by law (invoices, tax records) and which are shared (comments other people replied to).

### 2. Export

Add a self-serve export from account settings that produces a machine-readable file (JSON, with CSV where it helps) of the user's own data, generated on request and delivered by a signed, expiring link or a direct download. Exclude other users' personal data and internal fields.

### 3. Delete

Add account deletion from settings with a clear explanation and a confirmation step (re-enter the email or password). Delete or anonymise every personal row, uploaded files, and sessions; call third-party deletion APIs where they exist; keep only what the law requires, linked to an anonymised id. Cancel active subscriptions first.

### 4. Say what happens

Show what is deleted, what is kept and why (invoices, for example), and how long backups take to roll over. Add a test that deletion removes the user's personal rows from every table in the inventory.

## Done means

- [ ] Every place user data lives is listed, with what must be kept and why.
- [ ] Users can export their own data from settings.
- [ ] Users can delete their account from settings, and deletion reaches every table, file and third party listed.
- [ ] A test proves deletion removes personal rows from every listed table.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.