Data privacy & policy

You need a privacy policy to launch — the App Store, Google Play, Stripe, and most ad platforms all require one, and GDPR/CCPA apply the moment you have EU or California users (which, online, is immediately). The good news: doing this right is mostly discipline, not lawyering.

Collect less, sleep better

The cheapest way to handle user data well is to not hold it. Before you store a field, ask whether you actually need it. Data you don't have can't leak, can't be subpoenaed, and doesn't show up in a breach.

• Don't log full request bodies containing personal data.
• Don't store card numbers — let Stripe hold them; you keep only their token/customer id.
• Strip or hash anything sensitive you don't truly use.

The legal basics (plain version)

You don't need to be a lawyer, but you should know the shape:

• GDPR (EU/UK). Users can ask what you hold, get a copy, correct it, and have it deleted. You need a lawful basis to process data and must report serious breaches quickly. Get explicit consent before non-essential tracking/cookies.
• CCPA/CPRA (California). Users can see what you collect, delete it, and opt out of "sale/sharing" (which includes some ad-tech data flows). A "Do Not Sell or Share My Personal Information" path is expected if that applies to you.
• Consent for tracking. Analytics that fingerprint or track across sites generally need consent in the EU. Privacy-friendly setups (cookieless analytics, or PostHog configured without cross-site tracking) reduce the burden.

This is general guidance, not legal advice — when in doubt, get a real opinion.

Shipping a real privacy policy

Skip the scary-looking 30-page template that doesn't match your app. A good policy is honest and specific:

1. What you collect — account info, usage analytics, payment metadata, etc.
2. Why — to run the service, to bill, to improve the product.
3. Who you share it with — name your processors: Supabase (database), Stripe (payments), Vercel (hosting), your analytics and email tools.
4. How long you keep it and how users can request deletion.
5. Contact — a real email for privacy requests.

Generators (Termly, iubenda, your platform's template) get you 80% there; edit the sub-processor list to match your actual stack. A policy that lists tools you don't use is a red flag in review.

Make deletion actually work

"Right to be deleted" means you can do it. Build a path — even a manual one at first — to fully remove a user:

delete from sessions where user_id = $1;
delete from app_data where user_id = $1;
delete from users where id = $1;
-- then remove them from Stripe, your email list, and analytics

Remember the downstream copies: your email provider, error tracker, and analytics each hold data too. A deletion that leaves the user in Mailchimp isn't a deletion.

Handling a breach

Have a rough plan before you need one: contain it, rotate affected secrets, figure out what data was exposed, and notify affected users and (where required) regulators promptly. Quiet cover-ups are what turn an incident into a scandal.

Ship-ready when

• You collect the minimum data the app needs — no card numbers, no needless logging of personal data.
• A privacy policy is live, listing your real sub-processors and a contact email.
• Consent is handled for non-essential tracking where required.
• A delete-user path exists and clears downstream copies (email, analytics, Stripe).
• You have a basic breach-response plan.