--- slug: gdpr-for-vibe-coders title: "GDPR for Vibe-Coders: What Actually Matters" excerpt: "GDPR for vibe-coders without the legal scare. The five things regulators and users care about, the AI defaults that quietly break them, and a 30-minute audit." primaryKeyword: "GDPR for vibe-coders" publishedAt: 2026-08-20 readingTimeMin: 8 author: "Robert Boylan" tags: - gdpr - privacy - compliance - indie-dev - launch --- You launched the app to a few hundred users. Then someone in Germany emailed: "Where do I download all my data?" You blink. You search the app. There's no export button. You search your AI tool's transcripts. The privacy policy says users can request a data export. The button that fulfils that promise was never built. This is the GDPR-for-vibe-coders failure mode in one screenshot. You pasted a privacy policy template. You ticked the legal-pages box. Your AI-coded app builds against an assumption the privacy policy never made it back into. Now an actual EU resident is exercising an actual EU right, and the app doesn't honour it. This post is about the five things that actually matter under GDPR for an indie dev, what AI tools quietly get wrong by default, and the 30-minute audit that catches most of it. It's not legal advice. It's the practical reality of what regulators check and what users notice. ## What GDPR really is, in two sentences **GDPR** (the General Data Protection Regulation, the EU privacy law in force since 2018) sets rules for how anyone processing the personal data of EU residents has to handle it. If your app collects an email from anyone in the EU, GDPR applies, regardless of where you live. That's the trigger. Not "you have a company in the EU." Not "you target the EU." Just "you collect data from an EU resident." Which, for almost any indie app with an open signup, is true on day one. A note before continuing: this is an overview written by someone running a SaaS, not a lawyer. For high-stakes or jurisdiction-specific advice, talk to one. The point of this post is to stop the easy mistakes that an actual lawyer would also flag. ## The five things that actually matter Forget the seven principles, the ninety-nine articles, and the seventy recitals. For indie SaaS, GDPR enforcement comes down to five questions. If you can answer "yes" to all five, you're in better shape than 80% of small SaaS products. **1. Do you have a lawful basis for the data you collect?** GDPR says you can only process personal data if you have a legal reason. For most indie SaaS, the basis is "performance of a contract" (the user signed up; you need their email to provide the service) or "legitimate interest." Marketing emails to non-customers need consent. Service emails to customers don't. If you can describe in one sentence why you collect each piece of data, you have a lawful basis. **2. Can a user export their data?** If a user asks "give me everything you have about me," you must provide it in a machine-readable format (JSON or CSV) within 30 days. For an indie app, "export everything" is usually their account record plus whatever rows they own. A simple "Download my data" button on the account page that produces a JSON file is enough. **3. Can a user delete their account, including the data?** Right to erasure. The user clicks delete, the data is gone within 30 days (with exceptions for things you must keep, like billing records for tax purposes). "Gone" doesn't mean soft-deleted with a `deleted_at` column. It means actually removed, or anonymised so it can't identify them. **4. Do you have a list of who else processes your users' data?** These are called sub-processors. Stripe processes payments. Resend or Brevo processes emails. Supabase stores the database. PostHog records analytics. You need a list, with links to their privacy pages, in your privacy policy. EU users have the right to know who you're handing their data to. **5. Can you tell users if there's a breach?** If your database leaks or someone gets unauthorised access, you have 72 hours to tell affected users and (if it's serious) the relevant data protection authority. You don't need a fancy incident response plan. You need an honest commitment to notify, and a way to email all affected users when it matters. That's the working list. Everything else is detail. ## What AI-coded apps quietly get wrong The privacy policy says one thing. The code does another. Here are the most common mismatches when an AI tool builds the app. **Cookies before consent.** Lovable, v0, and Bolt-generated apps often include analytics scripts in the initial scaffold (PostHog, Plausible, Google Analytics) that fire on page load. If the user is in the EU and you haven't asked permission first, this is a violation. You need a consent banner, and you need to actually block the script until consent is given. The banner alone doesn't fix it if the script fires anyway. **Logging PII to the console.** AI tools love `console.log(user)` for debugging. In production, this writes the full user object (email, sometimes more) to your hosting provider's logs. If those logs sit in a US-based service, you've just transferred EU personal data outside the EU without a transfer mechanism. Audit your logs for email addresses; nuke the lines that don't need to be there. **No deletion path.** The AI builds the signup flow. The AI does not, by default, build a "delete my account" flow. The privacy policy says you can delete; the app doesn't expose the button. This is the most common audit miss and the easiest one to fix. **Storing more than you need.** The AI happily adds columns: `last_ip`, `user_agent`, `device_id`, `referrer_url`. Each is fine if you use it. Most are collected and never queried. GDPR's data minimisation principle says you should only collect what you use. Delete the columns you don't query. **Third-party services without disclosure.** The AI wires up Stripe, Resend, PostHog, OpenAI, Anthropic, and a vector store, and your privacy policy mentions one of them. Each external service that touches user data is a sub-processor and needs to be listed. **No data export.** Same shape as deletion. The policy promises it; the code doesn't ship it. If you find two or more of these in your app, you're in the typical place. Fix them. The fixes are usually a small day of work, not a refactor. ## The 30-minute audit If you have a working app and you've never explicitly checked the GDPR posture, set aside half an hour. The audit: **Minute 0 to 5: open the privacy policy.** Read it like a user. List every promise it makes ("you can delete your account," "we'll respond to data requests in 30 days," "we use these third parties"). Write each promise down. **Minute 5 to 15: open the app.** For each promise, find where it's honoured. If the policy says "you can delete your account," go find the delete button. If it says "you can export your data," find the export. If the button doesn't exist, mark it red. **Minute 15 to 20: open the database.** Look at every column on the users table. For each, ask: do I use this? If not, plan to drop it. Look for any column that smells like raw IP, user agent, or device fingerprint, and confirm you actually need it. **Minute 20 to 25: check the third-party list.** Open your hosting dashboard, your transactional email provider, your payment provider, your analytics tool. Make a list. Compare it to the privacy policy's sub-processor list. Anything in the first list that isn't in the second is a gap. **Minute 25 to 30: check the consent flow for EU users.** Open the site in an incognito window with a VPN set to a European country. Does an analytics script fire before you click "accept"? Open DevTools, Network tab, look for analytics requests. If they fire pre-consent, the consent flow is broken. By the end of the audit you have a list of gaps, ordered by impact. Most of them are fixable with a single AI prompt each ("add a 'delete my account' button to the account settings page; on click, run a confirmation dialog, then call the existing /api/account/delete endpoint that hard-deletes the user"). The audit doesn't replace [an honest legal pages review](/blog/legal-pages-for-indie-apps). It complements it. The legal pages post covers what to write; this post covers whether what you wrote matches what the app does. ## Capture GDPR posture in the spec The pattern that prevents these problems is the same as everywhere else in vibe-coding: write it down before the AI improvises. When you describe the app in your project spec, include a one-line "Privacy posture" note. "EU-friendly. Users can export and delete their account. Analytics scripts blocked until consent. No PII in server logs." Four sentences. Drop them into the constraints or notifications section. Cursor, Lovable, or Claude Code reading the spec will now build the deletion endpoint, the export endpoint, and the consent gate as part of the initial scaffold, instead of leaving them as work for later. This is one of the things a [thoughtful app spec](/what-is-a-prd) covers that a one-line prompt doesn't. The AI doesn't infer compliance posture from "build a habit tracker"; it infers it from what you wrote down. If "EU-friendly" is in the spec, the build accounts for it. If it isn't, the build doesn't, and you're doing the audit on launch night instead of build night. Most indie founders panic about GDPR because they treat it as a 99-article wall of law. The reality for a small SaaS is closer to a five-point checklist and a half-hour audit. Do the work once, capture the posture in the spec, and the app stays compliant as it grows. Skip it, and the first email from a German user becomes the start of a much longer afternoon.