GDPR/CCPA for Developers: A No-Lawyer-Needed Pre-Launch Checklist

GDPR (EU) and CCPA (California) sound like lawyer problems. They're not — they're developer problems, and the implementation work falls on you. Here's the no-jargon checklist for what to build before launch.

The good news: for most small apps, compliance is a handful of features, not a legal department. The bad news: those features are easy to forget, and getting them wrong is expensive.

What GDPR and CCPA actually require (for developers)

Strip away the legalese and both regulations require roughly the same four things:

1. Tell users what you collect and why. A privacy policy, plus just-in-time disclosures (e.g., "we'll use your email to send receipts").
2. Get consent for non-essential data collection. Cookie banners for analytics/ads, opt-in for marketing email, explicit consent for sensitive data.
3. Let users access, export, and delete their data. A "download my data" button and a "delete my account" button that actually works.
4. Don't keep data longer than you need it. Retention policies and scheduled deletion.

That's it. The rest is process and documentation.

The pre-launch developer checklist

1. Classify your data

Before you can protect user data, you have to know where it is. List every piece of PII (personally identifiable information) your app collects, where it's stored, and who can access it.

For a typical SaaS: email, name, password hash, payment processor token, IP addresses in logs, maybe uploaded files. Each one needs a storage location, a retention period, and an access policy.

2. Build the data export feature

GDPR Article 15 gives users the right to "data portability" — they can ask for a machine-readable export of their data. CCPA has a similar provision.

Don't wait for the request. Build a "Download my data" button in settings that exports the user's data as JSON. It's an afternoon of work, and it turns a 30-day legal deadline into a self-serve click.

3. Build the account deletion feature

GDPR Article 17 is the "right to erasure" — users can ask you to delete their data. CCPA has the same.

The button is easy; the hard part is the cascade. When a user deletes their account, you need to delete (or anonymize) their records in every table, every backup rotation, every third-party service (Stripe, Mailchimp, your analytics tool). Miss one and you're non-compliant.

The pragmatic approach: soft-delete in the database immediately, hard-delete in the next backup rotation, and keep a list of third-party services to purge manually.

4. Implement a cookie consent banner (if you use cookies)

If you use Google Analytics, AdSense, or any third-party script that sets cookies, EU/UK users must consent before the script loads. Not after. Before.

This means your banner has to block non-essential scripts until the user accepts. Tools like CookieYes, Osano, or a custom banner with data-blocked attributes on scripts handle this. The free tiers are sufficient for small sites.

If you use a cookieless analytics tool like Umami or Plausible, you can skip the banner entirely for analytics — but you still need one if you run ads.

5. Write a real privacy policy

Not a copied-and-pasted template. A privacy policy that accurately describes:

• What data you collect (be specific: "email, name, hashed password, IP addresses in logs for 30 days")
• Why you collect it (each purpose, tied to the data)
• Who you share it with (Stripe, your host, your email provider — name them)
• How long you keep it (retention periods per data type)
• How users can access, export, or delete it (link to the features you built in steps 2 and 3)
• How to contact you

Host it at /privacy. Link it in the footer. Google AdSense will reject you without one; app stores require one; EU regulators check for one.

6. Honor "Do Not Sell or Share My Personal Information" (CCPA)

CCPA gives California residents the right to opt out of having their data "sold" or "shared." For most small apps, "sell" doesn't apply (you're not selling data). But "share" can include retargeting pixels and some ad networks.

If you run ads with retargeting, add a "Do Not Sell or Share My Personal Information" link in your footer that disables the retargeting script. If you don't run retargeting, you can skip this — but document that decision.

7. Set retention policies and implement them

Data you don't have can't be breached and doesn't need to be deleted on request. Set retention periods:

• Logs: 30 days, then auto-delete.
• Inactive accounts: 2 years of inactivity, then email warning, then deletion.
• Session data: expires on logout or after 30 days.
• Backups: rotate so a deleted user's data ages out within 30–90 days.

Write a cron job that enforces these. Untested retention is a liability, not a policy.

8. Document your subprocessors

GDPR requires a Data Processing Agreement (DPA) with every third party that touches user data. For a small SaaS, that's typically:

• Your hosting provider (Vercel, AWS, etc. — they all have standard DPAs)
• Your database provider (Supabase, Neon, etc.)
• Your email provider (Resend, Postmark, etc.)
• Your payment processor (Stripe — they have a DPA)
• Your analytics (if any)

Most providers have a signed DPA ready to accept in their dashboard. Do it once, keep the list in your docs.

What you don't need (yet)

• A Data Protection Officer (DPO) — only required for large-scale processing of sensitive data, or public authorities.
• Records of processing activities (ROPA) in a formal registry — required for orgs with 250+ employees or high-risk processing. A Notion doc listing your data flows is fine for smaller orgs.
• Data Protection Impact Assessments (DPIAs) — only for high-risk processing (biometrics, large-scale tracking, etc.).

The 80/20 for launch

If you do nothing else before launch:

1. Privacy policy at /privacy (30 minutes, use a generator and customize it).
2. Cookie consent banner if you use analytics or ads (1 hour with a free tool).
3. "Delete my account" button that actually deletes (an afternoon).
4. "Download my data" button that exports JSON (an afternoon).

That covers 90% of small-app compliance. The rest can come as you scale — but do those four before you have users, not after a regulator emails you.

Run the ShipReady Data & Compliance checklist to make sure you haven't missed anything stack-specific.