The three things a vibe-coded app forgets before launch are a working consent banner, an honest privacy policy, and server-side access control on its database. The first two are legal disclosures. The third is the one that turns a missing detail into a reportable data breach, because an AI builder will happily wire your app to a public database and never mention that anyone with the URL can read it.
Shipping fast is the whole point of tools like Lovable, Bolt, v0, Replit and Base44. The problem is that "it works" and "it is safe to publish" are different tests, and the generator only checks the first one. This checklist covers the legal and security items an AI-built app skips, ordered so the launch-blockers come first.
What does a vibe-coded app actually ship on launch day?
A vibe-coded app ships a working frontend, a hosted backend such as Supabase or Firebase, and an API key baked into the client so the two can talk. That is a functioning product. It is not a compliant one. The generator produces code that runs, not the consent logic, legal pages, access rules, or data-handling processes that publishing to real users requires. That distance between what the tool outputs and what the law expects is the compliance gap, and it exists on every platform because none of them can read your prompt and infer which jurisdictions you serve or which cookies you set.
Two facts make this your problem rather than the tool's. The prompt creates no legal shield: under the GDPR, whoever deploys the app and decides why data is collected is the controller, no matter who or what wrote the code. And the list of what AI builders do not generate runs well past a banner, taking in policies, processor records, deletion routes, and the security layer covered below.
Does your app need a cookie consent banner?
Your app needs a consent banner if it sets any cookie or similar identifier that is not strictly necessary and it has visitors in the EU, the UK, or a growing list of other regions. A login session cookie is exempt. Analytics, advertising pixels, embedded YouTube or Stripe scripts, and anything a third party drops are not, and they need informed, prior consent before they load. The rule is Article 5(3) of the ePrivacy Directive, and it bites the moment a non-essential script runs, not when someone clicks something.
Regulators treat the reject button as the test. The French CNIL fined Google EUR 325 million in September 2025 for setting advertising cookies at account creation without valid consent, and on the same day fined SHEIN's Irish subsidiary EUR 150 million partly because clicking "Reject all" still installed tracking cookies. A banner with only an "Accept" button, or one that loads scripts before the visitor chooses, is worse than no banner, because it documents the violation. Wiring up cookie consent that genuinely blocks scripts until a choice is made is the fix.
What has to be in your privacy policy?
A privacy policy is a mandatory disclosure the moment your app collects a single piece of personal data, including an email in a contact form. It must name what data you collect, why, the legal basis for each purpose, how long you keep it, who you share it with, and how a user exercises their rights. A generic template copied from another site fails on the details that matter: it will not list your actual third parties or match what your app really does. The GDPR sets this duty in Articles 13 and 14; equivalent rules exist under the UK GDPR, the LGPD, and US state laws.
Your terms of service are a separate document doing a different job. They govern the contract between you and the user, covering acceptable use, liability, and account termination. Neither document is generated for you.
Do you have the security layer the generator skipped?
The most common way a vibe-coded app fails is not a missing banner. It is a database with Row-Level Security switched off and a privileged key sitting in the browser bundle, which lets anyone with the URL read or change every row. This single failure mode sits behind most vibe-coding breaches. Wiz Research found in September 2025 that roughly one in five vibe-coded apps it scanned carried this class of risk, usually because the generated Supabase policies were missing or far too permissive.
The scale is not theoretical. Researchers found that around one in ten of 1,645 Lovable-showcased apps were leaking user data through missing Row-Level Security, a flaw catalogued as CVE-2025-48757. In January 2026 an AI social network called Moltbook, built entirely by prompting, exposed roughly 1.5 million API keys and 35,000 email addresses through a client-side Supabase key with Row-Level Security never enabled. GitGuardian's 2026 State of Secrets Sprawl report counted 28.65 million new hardcoded secrets pushed to public repositories in 2025, with AI-assisted workflows leaking at roughly double the baseline rate.
Clear the security layer before anything else. Run through this before you deploy:
Row-Level Security: every table in your public schema has RLS enabled with a policy that scopes rows to the authenticated user.
No secrets in the client: search the codebase for any variable prefixed
NEXT_PUBLIC_orVITE_that holds a service-role key or API secret, move it server-side, and rotate anything that ever shipped to the browser.Server-side validation: every endpoint validates input on the server, not only in the form, so an attacker calling the API directly cannot bypass it.
Authorisation checks: confirm each route checks not just whether a user is logged in but whether that user is allowed to touch that specific record.
Who counts as a data processor in your app's stack?
Every third-party service that touches your users' personal data on your behalf is a processor, and that list is longer than founders expect: the host (Vercel, Netlify, Firebase), the database (Supabase), any AI API you call, the payment provider, the email sender, and your analytics tool. Each one needs a data processing agreement in place, and the GDPR expects you to keep a record of processing activities under Article 30 that lists them, what data each handles, and where it sits. Most vibe-coded apps have neither, because the generator adds the SDK without ever mentioning the paperwork that legally comes with it.
Can your app handle a data deletion request?
Under the GDPR you have one month to respond when a user asks to see or delete their data, and you must be able to actually find, export, and erase it. A data subject access request covers requests to see everything you hold on a person; the right to erasure covers requests to delete an account and everything attached to it. Vibe-coded apps routinely ship with no admin route to do either, since there is a sign-up flow but no delete-user function, and user rows sit scattered across tables with no clean way to remove them. Build that capability before launch, or the first request becomes a compliance incident you cannot answer in time.
What about visitors from the US and any email you send?
US privacy law works on an opt-out model rather than consent. If you have visitors in California and you share data with advertising or analytics partners, you need a clear do not sell or share mechanism, and more than a dozen states now run comparable laws. The requirements differ enough by region that checking the privacy laws around the world that apply where your users actually are is worth doing before launch, not after.
Any email your app sends carries its own rules. Transactional and marketing messages both need a genuine sender identity and a working unsubscribe path under US CAN-SPAM and the UK's PECR. A welcome email from a no-reply address with no opt-out is a common, avoidable slip.
The pre-launch checklist at a glance
Run every row before you deploy. The security and consent items are launch-blockers; the rest belong on the list before you send the first user a link. A scan your app step confirms what cookies and scripts actually load, since the real list is usually longer than the code suggests.
| Checklist item | Why it blocks launch | How to check |
|---|---|---|
| Row-Level Security | Public database is readable by anyone with the URL | Every public table has RLS on with a per-user policy |
| No client-side secrets | A leaked service key is an admin backdoor | No service-role key in NEXT_PUBLIC_ or VITE_ variables |
| Consent banner | Non-essential cookies without consent breach ePrivacy | Scripts blocked until consent, with a real reject button |
| Privacy policy | Mandatory disclosure once any personal data is collected | Lists real data, purposes, processors, and user rights |
| Terms of service | No contract governing use, liability, or termination | Published and linked in the footer |
| Processor records and DPAs | Article 30 record and processor contracts are required | Every third party listed with an agreement in place |
| Delete and access route | One-month deadline to fulfil data requests | Admin function to export and erase a user's data |
| US opt-out and email rules | State laws and CAN-SPAM apply to US users and email | Do-not-sell control and a working unsubscribe link |
Frequently Asked Questions
Is an AI-built app exempt from GDPR?
No. Whoever deploys the app and decides why data is collected is the data controller and carries the legal responsibility, regardless of whether a human or an AI tool wrote the code.
Do I need a cookie banner if my app only uses a login cookie?
A strictly necessary session or login cookie needs no consent. The banner becomes mandatory as soon as you add analytics, advertising pixels, or embedded third-party scripts.
What is the most common security flaw in vibe-coded apps?
A database with Row-Level Security disabled combined with a privileged API key exposed in client-side code, which lets anyone with the URL read or modify the entire database.
How quickly must I respond to a delete-my-data request?
Under the GDPR you have one month from the request, and you must be able to locate, export, and permanently erase that user's data across your app.
Do I need a privacy policy if I only collect email addresses?
Yes. Collecting any personal data, including a single email address in a contact form, triggers the duty to publish a privacy policy explaining what you collect and why.
Can I launch first and add compliance later?
The app is legally live the moment it collects data, so the highest-severity items, database security and consent, should be fixed before launch rather than after the first user or complaint.
Get consent live before you launch
If your app collects data, the consent banner and cookie policy are the parts you can put in place today, without touching the code the generator wrote. Kukie.io scans a live site for the cookies and scripts it actually loads, sorts them into categories, and serves a banner that blocks non-essential scripts until a visitor agrees.
