GDPR checklist for a SaaS MVP: 20 privacy defaults for vibe-coded apps

Short answer: a GDPR checklist for a SaaS MVP comes down to six habits you can set up before launch. Collect only the data your product needs. Don't load trackers or set non-essential cookies before a visitor agrees. Publish a privacy page that names the tools that handle customer data. Sign the data processing agreements those tools already offer. Make "delete my account" actually delete. And write down who you'd call if data leaked. Below is a first-visit privacy probe we ran on Nov 11, 2026, the script so you can run it on your own site, and a 20-item checklist. This is plain-English guidance, not legal advice. If you'd like an engineer to look at your live app with you, our launch check for AI-built apps covers privacy alongside security, speed and the bill.

This guide is for founders who built their product with Lovable, Bolt, Cursor, Replit or v0, usually on top of Supabase or Firebase, Vercel, Stripe and an AI API, and who now have (or expect) customers in the UK or EU. AI builders are great at shipping a waitlist form, an analytics snippet and a chat feature in an afternoon. They don't ask what happens to the emails in that form, which cookies that snippet drops, or where the chat transcripts end up. Those are exactly the questions a first B2B customer's security questionnaire will ask.

Does GDPR apply to my small app?

Probably, if you have users in Europe. The GDPR applies to businesses outside the EU when they offer goods or services to people in the EU or monitor their behaviour there (Article 3(2)). The UK has its own near-identical version, the UK GDPR, plus cookie rules under PECR. There's no "too small to count" exemption for the core rules. A few duties, like keeping formal records of processing, have narrow exemptions for small companies, but a SaaS that processes customer data every day rarely fits them.

The good news: for an MVP, most of the work is defaults, not paperwork. If your app is set up sensibly, the privacy page almost writes itself.

Original test: what does your site do before anyone clicks "Accept"?

The most common GDPR problem we see on vibe-coded sites is invisible to the founder: the page sets cookies and loads trackers the moment it opens, before a consent banner (if there is one) gets a click. Under the EU ePrivacy rules and the UK's PECR, non-essential cookies and similar tracking need consent first. Only strictly necessary ones, like a login session the user asked for, are exempt.

So we wrote a small script that fetches a page the way a first-time visitor would, with no clicks, and reports six things:

1. Cookies set by the first response. 2. Third-party hosts the page loads straight away (scripts, iframes, pixels, stylesheets). 3. Known analytics and tracker markers in the HTML (Google tag, Meta Pixel, Hotjar and others). 4. Whether /privacy, /privacy-policy, /cookies and /terms exist. 5. Whether the home page links to a privacy page. 6. Whether there's any consent-banner marker at all.

Result 1: blitzhash.com

We ran it against our own site first, on Nov 11, 2026 at about 6:05 AM PT:

== 1. Cookies set by the first HTML response (before any consent click)
   none
== 2. Third-party hosts the page LOADS on first visit
   none
   (plain outbound links, not loaded until clicked: 8 hosts)
== 3. Known tracker / analytics markers in the HTML
== 4. Privacy pages reachable
   /privacy -> 200
   /privacy-policy -> 200
   /cookies -> 200
   /terms -> 200
== 5. Link to a privacy page from the home page
   href="/privacy"
== 6. Consent banner markers
   none found

No cookies and no third-party loads on first visit, so there's nothing that needs a consent banner. The eight outbound hosts are ordinary links (social profiles, GitHub, Calendly) that send nothing until someone clicks them.

Result 2: a typical AI-built landing page

Then we built a small demo page that looks like what an AI builder often produces when you ask for "a waitlist page with analytics": a Google Fonts stylesheet, the Google tag, a Meta Pixel, Hotjar, and a server that sets a session cookie and a one-year A/B test cookie. We served it locally and ran the same script:

== 1. Cookies set by the first HTML response (before any consent click)
Set-Cookie: session_id=abc123…; Path=/
Set-Cookie: ab_test_variant=b…; Path=/; Max-Age=31536000
== 2. Third-party hosts the page LOADS on first visit
      1 www.googletagmanager.com
      1 www.facebook.com
      1 static.hotjar.com
      1 fonts.googleapis.com
== 3. Known tracker / analytics markers in the HTML
   found: googletagmanager.com (1)
   found: gtag( (3)
   found: fbq( (2)
   found: connect.facebook.net (1)
   found: hotjar (2)
   found: fonts.googleapis.com (1)
== 4. Privacy pages reachable
   /privacy -> 404
   /privacy-policy -> 404
   /cookies -> 404
   /terms -> 404
== 5. Link to a privacy page from the home page
   none found
== 6. Consent banner markers
   none found

Every line here is a fix. Two cookies before any consent, one of them kept for a year and not needed for anything the visitor asked for. Four outside companies receive the visitor's IP address and browser details on page load. No privacy page, no cookie page, no banner. A session cookie for a logged-in user is usually fine without consent. A session cookie on an anonymous landing page, plus a year-long A/B cookie, usually isn't.

Run it on your own site

Save this as privacy-probe.sh, run chmod +x privacy-probe.sh, then ./privacy-probe.sh https://your-site.com. It needs only bash and curl. (The fuller version we ran prints "none" for empty sections; this shorter one leaves them blank.)

#!/usr/bin/env bash
# privacy-probe.sh: first-visit privacy check (no browser, no consent click)
set -u
URL="${1:?usage: privacy-probe.sh https://your-site.com}"
HOST=$(echo "$URL" | sed -E 's#https?://([^/]+).*#\1#')
BASE=$(echo "$HOST" | awk -F. '{print $(NF-1)"."$NF}')
TMP=$(mktemp -d)
curl -sS -L -D "$TMP/h" -o "$TMP/b" -A "Mozilla/5.0 privacy-probe" "$URL"

echo "== 1. Cookies set before any consent"
grep -i '^set-cookie:' "$TMP/h" | cut -d';' -f1-3 || true

echo "== 2. Third-party hosts loaded on first visit"
{ grep -oiE 'src="https?://[^"/]+' "$TMP/b"
  grep -oiE 'rel="stylesheet"[^>]*href="https?://[^"/]+' "$TMP/b" | grep -oiE 'https?://[^"/]+'
} | sed -E 's#.*://##' | grep -viE "(^|\.)${BASE}$" | sort | uniq -c | sort -rn

echo "== 3. Tracker markers"
for m in googletagmanager.com google-analytics.com 'gtag(' 'fbq(' connect.facebook.net \
         hotjar clarity.ms posthog mixpanel segment.com intercom tiktok fonts.googleapis.com; do
  c=$(grep -oiF "$m" "$TMP/b" | wc -l); [ "$c" -gt 0 ] && echo "   found: $m ($c)"
done

echo "== 4. Legal pages"
for p in /privacy /privacy-policy /cookies /terms; do
  echo "   $p -> $(curl -s -o /dev/null -w '%{http_code}' -L "https://$HOST$p")"
done

echo "== 5. Privacy link on the home page"
grep -oiE 'href="[^"]*privacy[^"]*"' "$TMP/b" | sort -u | head -3

echo "== 6. Consent banner markers"
grep -oiE 'cookie[- ]?(consent|banner|notice)|cookiebot|onetrust|termly|iubenda|klaro|osano' "$TMP/b" | sort | uniq -c
rm -rf "$TMP"

Know its limits. The script reads the HTML your server sends. Apps built as single-page React apps often inject trackers later with JavaScript, so a clean result isn't proof. Do the browser check too: open your site in a private window, open DevTools, and before clicking anything look at Application → Cookies and the Network tab filtered to third-party domains. Anything from an analytics, ads or session-recording company that shows up before you click "Accept" is a finding.

The GDPR checklist for a SaaS MVP

Here's the checklist. It's ordered by what tends to go wrong first in AI-built apps. Copy it into your launch notes and tick it off.

Collect less (data minimisation)

1. List every field you collect on signup, onboarding, checkout and support forms, and delete any you can't name a use for. GDPR's data minimisation principle (Article 5(1)(c)) means "might be useful later" isn't a reason. 2. Check what your AI features store. Chat transcripts, uploaded files and prompts often get saved to a table "for history" by default. Decide whether you need them, and for how long. 3. Keep personal data out of logs and error trackers. AI-written code often logs whole request bodies, which means emails, addresses and sometimes passwords end up in your hosting logs. Log IDs, not people. Most error trackers have a setting to scrub sensitive fields; turn it on.

Cookies and trackers

4. Run the probe and the DevTools check above on your home page, signup page and logged-in dashboard. 5. Load analytics, pixels and session recording only after consent. If you use a consent tool, check that it actually blocks scripts until the click. Many installs show a banner while the tags have already fired. 6. Make "Reject" as easy as "Accept". UK and EU regulators have repeatedly said that burying the reject option doesn't give valid consent. 7. Consider a cookieless setup. If you only need page views, a privacy-focused analytics tool that sets no cookies can remove the need for a banner entirely. Check the tool's own documentation before assuming it. 8. Self-host fonts rather than loading them from a third-party font service on every page view, so visitor IPs aren't sent to another company for a typeface.

Tell people (transparency)

9. Publish a privacy page that says what you collect, why, which lawful basis you rely on (Article 6, usually "contract" for running the account and "consent" for marketing), how long you keep it, and how to contact you. Article 13 lists what it must include. 10. Name your processors: hosting, database, payments, email, analytics and any AI API that sees customer data. A short list is far better than "trusted third parties". 11. Link the privacy page from your footer and from every form that collects personal data.

Contracts with your tools

12. Accept the data processing agreements (DPAs) your providers already publish. Vercel, Supabase and Stripe each publish one, and most other major providers do too. Article 28 requires a written contract with anyone who processes personal data for you. For most MVPs this is a matter of finding the page and keeping a record that it applies. 13. Check where data is stored and whether your database region matches what you tell customers. Moving regions later is a real migration, so choose before launch. 14. Check your AI provider's data settings: whether API inputs are used for training, and how long they're retained. Read the provider's current policy and write down what it says.

Rights requests and deletion

15. Make account deletion real. Test it: create a user, add data, upload a file, then delete the account. Check every table, your file storage, your email tool and your payment provider's customer record. Article 17 gives people the right to erasure, and "we set a deleted flag" usually isn't enough. 16. Be able to export one person's data on request. A saved database query that pulls everything for one user ID is a fine start. 17. Put a reminder system in place. You generally have one month to respond to a rights request, extendable by two further months for complex cases (Article 12(3)). A shared inbox nobody reads breaks that quickly.

Retention and breaches

18. Set retention periods for inactive accounts, logs, backups and chat history, and automate the deletion where you can (Article 5(1)(e), storage limitation). 19. Write a one-page breach plan: who decides, how you find out which users were affected, and who tells whom. If a breach is likely to put people at risk, the GDPR expects you to notify the regulator within 72 hours of becoming aware of it (Article 33). That clock is hard to meet if you're working out the plan on the day. 20. Lock down access to production data. Every co-founder, freelancer and AI agent with database access is part of your privacy story. Remove the ones who don't need it. Our plain-English application security audit checklist covers the access side in more depth.

What AI builders usually get wrong

Four patterns come up again and again in AI-built apps:

• Analytics pasted into the root layout. The builder adds the tag where you asked, which means it runs on every page before any banner logic.
• Soft delete only. "Delete account" signs the user out and flips a flag, while their profile, files and Stripe customer stay put.
• Everything in one log line. Debug logging added during a build session ships to production and quietly collects personal data for months.
• No owner for privacy email. The privacy page lists an address that forwards to nobody.

None of these take long to fix once you know they're there. They're also the kind of thing a larger customer's procurement team will ask about, so fixing them early helps you close deals. If you're preparing for launch in general, our Cursor app production checklist pairs well with this one.

A free tool for the rest of the launch

Privacy is one part of launch readiness. Our open-source BlitzHash Launch-Ready Check scans a live URL for common launch gaps like missing security headers and leaked keys. You can also run our free self-check in a few minutes.

FAQ

Do I need a cookie banner if I don't use any trackers?

Often not. Strictly necessary cookies, such as a login session the user asked for, don't need consent. If the probe and your DevTools check show no analytics, ads or session-recording cookies or scripts before consent, you may not need a banner at all. You still need a privacy page.

Is a privacy policy generator enough?

It's a starting point, not the finish line. A generated policy only helps if it matches what your app really does: the tools it names, the data it lists and the retention periods. Run the checklist first, then edit the policy to match.

My company isn't in the EU. Do I need an EU representative?

Possibly. Article 27 says non-EU businesses covered by the GDPR generally need a representative in the EU, with an exemption for occasional, low-risk processing. The UK has a similar rule. This one depends on your situation, so it's worth a short conversation with a privacy professional.

Does using GDPR-compliant providers make my app compliant?

No. Vercel, Supabase or Stripe being compliant covers their part. What data you collect, which trackers you load, how deletion works and who has access are your decisions, and they're where most problems are.

Want help checking your app?

If you'd like an engineer to run these checks with you and tell you plainly what to fix, book a free technical assessment through our launch check for AI-built apps. We'll look at privacy, security, speed and costs together, so you know what matters before your next customer asks.