Vibe coding and GDPR: the pre-launch checklist for AI-built apps

The short answer

An app built by prompt is an app like any other. If it collects anything about people in the EU, from an email address to an analytics cookie, the GDPR applies, and if it stores or reads anything on their devices, the ePrivacy rules apply too. That holds wherever you are based, as long as you offer the app to people there.

The good news: for a typical vibe-coded app the work is small and mostly one-off. Pick an EU region, sign the processor agreements, lock down the database, keep trackers off until people agree, and write two honest pages. The checklist at the end takes about an afternoon.

Who is responsible: you, not the builder

The AI builder made the code, but you decide what the app does with people's data. That makes you the controller under the GDPR. The services that store and process data for you, such as Supabase, your host and your email provider, are processors. For each of them you need a data processing agreement under Article 28.

The builder itself plays two roles. For your own account and prompts it is a service you use. For the data of your app's users it is a processor only if it hosts that data, for example through Lovable Cloud or Bolt Cloud. Our German posts on Lovable, Bolt, v0 and Replit go through each one in detail.

Data and hosting

1. Choose an EU region for user data. The GDPR does not require data to stay in the EU, but it makes your life easier and it is what customers ask first. Supabase offers six European regions, including Frankfurt (eu-central-1), Ireland, Paris, Stockholm, London and Zurich. Lovable Cloud lets you choose between the Americas, Europe and Asia-Pacific. Bolt Cloud runs on Netlify and Supabase; if you need a provable EU location there, connect your own Supabase project. Pick the region when you create the project; Supabase's documentation does not describe moving an existing project.

2. Sign the processor agreements. Make a list of every service that touches user data and check that you have a DPA with each. Supabase's DPA is part of its terms and includes the EU Standard Contractual Clauses. Its contracting party is Supabase Pte. Ltd. in Singapore, so the transfer question is answered by those clauses, not by an adequacy decision. Do the same for your email provider, your payment provider and any AI API.

3. Collect less. AI builders like to add fields. Every form field, every column and every log line is data you have to protect, explain and delete. Remove what you do not need before launch, not after.

Security: the RLS trap

4. Turn on Row Level Security for every table. This is the most common serious problem in vibe-coded apps. A Lovable or Bolt app talks to Supabase straight from the browser with a public key. That is safe only if the database decides per row who may read and write. Supabase's documentation is blunt: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." In other words, anyone who opens DevTools can read your users' data.

Check it in the Supabase dashboard: every table in the public schema needs RLS enabled and at least one policy. Then test it. Sign in as one test user and try to read another user's rows. The Security Advisor in the Supabase dashboard flags tables without RLS. Article 32 GDPR requires appropriate security, and an open table is the kind of breach you would have to report.

5. Keep secrets out of the frontend. The service role key, Stripe secret keys and AI API keys never belong in client code or in a VITE_ variable, because everything in a Vite build ships to the browser. They belong in server functions such as Supabase Edge Functions.

What runs in the browser

6. Keep trackers off until people agree. Analytics, pixels, session replay and embedded videos need consent in the EU and the UK before they load. A banner built by prompt usually renders after the trackers in index.html have already run, so it looks right and blocks nothing. Our Lovable cookie banner guide explains why and what works, and Does GA4 need cookie consent? covers Google Analytics specifically.

7. Check the builder's own extras. Lovable switches on its own visitor analytics by default, outside your code. Decide whether you want it, and check what it does, before your banner and privacy policy claim anything about it.

8. Host fonts yourself and gate embeds. AI builders often load Google Fonts from Google, which sends every visitor's IP address there. Ask the agent to install the fonts locally instead. YouTube videos, maps and social widgets need the same care. Our German posts on Google Fonts and YouTube include prompts for this.

The login session itself is fine. Keeping users signed in is strictly necessary and needs no consent; see Does Supabase auth need cookie consent? for the details and the one caveat.

AI features inside your app

9. Treat the AI API as a processor. If your app sends user input to OpenAI, Anthropic, Google or another model provider, that provider processes personal data for you. Use the provider's API terms with a DPA, not a consumer account, check whether inputs are used for training and how long they are kept, and name the provider in your privacy policy. Avoid sending more than the feature needs: a summary feature rarely needs the user's email address in the prompt.

The pages and paperwork

10. Write a privacy policy that matches the app. Article 13 requires you to tell people what you collect, why, on what legal basis, who receives it, where it goes, how long you keep it and what rights they have. A generated template is a starting point; the list of services must match what your app really uses. If you sell to German users, you also need an imprint under § 5 of the Digital Services Act (DDG).

11. Keep a short record of processing. Article 30 asks for a record of your processing activities. For a small app this is a table with five or six rows: user accounts, payments, emails, analytics, support, AI features. It takes an hour and it is the first thing an authority or a business customer asks for.

After launch

12. Plan for requests, breaches and the next prompt. Users can ask for a copy of their data or for deletion, and you have a month to answer. Make sure you can find and delete one user's rows across all tables. If data leaks, Article 33 gives you 72 hours to notify the supervisory authority. And every prompt can add a new script or tracker. Rescan the published app after each larger change, not only the day you launch.

The checklist

1. User data in an EU region, chosen when the project was created.
2. DPA with every processor: database, host, email, payments, AI API.
3. Only the fields and logs the app really needs.
4. Row Level Security on every table, with policies, tested with two accounts.
5. No secret keys in client code or VITE_ variables.
6. Consent banner loaded first in index.html, trackers blocked until consent, Reject all on the first layer.
7. Builder analytics checked and either documented or switched off.
8. Fonts hosted locally, embeds behind consent.
9. AI provider under API terms with a DPA, minimal data in prompts.
10. Privacy policy that names the real services, imprint if you target Germany.
11. Record of processing activities.
12. A way to export and delete one user's data, a breach plan, a rescan after big changes.

FAQ

Does the GDPR apply to a side project or a free app?

Yes, as soon as you offer it to people in the EU and process their personal data. There is no exemption for small or free apps. The only exception is purely personal or household use, which a public app is not.

Is Lovable GDPR compliant?

Lovable can be used in a GDPR compliant way, but compliance is a property of your app, not of the builder. You choose the region, sign the DPAs, lock down the database and handle consent. Our German post Ist Lovable DSGVO-konform? covers the details.

Do I need a cookie banner for my vibe-coded app?

Only if the app uses storage or scripts that are not strictly necessary, such as analytics, pixels, session replay or embedded videos. An app with only a login and no trackers usually does not. Most apps add analytics sooner or later, and then you do.

What is the biggest GDPR risk in a Lovable or Bolt app?

A Supabase table without Row Level Security. It exposes user data to anyone who looks, and it is a reportable breach. Check it before anything else.

Can I ask the AI agent to make my app GDPR compliant?

You can ask it to do specific tasks: enable RLS, host fonts locally, remove a field, add a checkbox. A general request produces text and components that look compliant without checking anything. Do the checks yourself, with the list above.

Do I need a data protection officer?

Usually not for a small app. A DPO is required when your core activity is large-scale monitoring of people or large-scale processing of sensitive data, and in Germany also when 20 or more people regularly process personal data.

Sources

1. Supabase docs, “Row Level Security”, read 5 October 2026
2. Supabase docs, “Available regions”, read 5 October 2026
3. Supabase, Data Processing Addendum, version of 1 August 2026
4. GDPR Article 28, processor
5. GDPR Article 30, records of processing activities
6. GDPR Article 32, security of processing
7. GDPR Article 33, notification of a personal data breach
8. GDPR Article 13, information to be provided
9. GDPR Article 37, designation of the data protection officer
10. § 38 BDSG, data protection officers of non-public bodies
11. § 5 DDG, general information obligations (imprint)
12. Directive 2002/58/EC (ePrivacy Directive), Article 5(3)

Written by the CookieCrumbs team, published 5 October 2026. Facts carry their dates; if one has moved on, tell us and we will correct it. This is not legal advice.