Is your Lovable app legally compliant? A 7-point checklist

Lovable's default output is fast but not legal-by-default. The model has clear preferences — placeholder-only inputs, GA4 on first load, Stripe keys in NEXT_PUBLIC_*, permissive Supabase RLS — that show up in almost every production scan we run. Here's what to check, in what order, with what each one costs if it fires.

What Lovable ships by default

Lovable's prompt-to-app mode produces React + Tailwind + Vite + Supabase, deployed to a `lovable.app` subdomain (custom domain on paid tiers). The defaults are functional but skip several review steps that established teams used to do at handoff:

• Inputs use placeholder text instead of real <label> elements
• Analytics (usually GA4 or Plausible) wired into the root layout, no consent gate
• Stripe keys sometimes both prefixed NEXT_PUBLIC_*, exposing the secret to the client
• Supabase Row Level Security often disabled or wildcarded on tables
• AI-generated terms of service and privacy policy that make claims the app can't back up
• Public deploy URL means staging surfaces (debug routes, test data) are crawlable
• Image-generation features that occasionally reproduce trademarked logos

Most of these are tolerable when you have ten test users. They become exposure when you have paying customers — especially in New York / Florida / California or with EU traffic.

The 7 things to check on a Lovable app

1. Form labels and input accessibility

Lovable defaults to placeholder text inside inputs ("Email" floating in the box). Screen readers can't see placeholders — this is WCAG 2.2 §1.3.1 / §3.3.2, the #1 most-cited rule in ADA demand letters. Fix: every input gets a real `<label>` with `htmlFor` matching the input's `id`. Visually hide if you don't want it on screen.

2. Color contrast on Tailwind defaults

Lovable's color choices lean pale — gray-400 or gray-500 text on white backgrounds, light blue links on cream. Most fail WCAG 2.2 §1.4.3 (4.5:1 minimum). Check every text/background combination. Tailwind's gray-700+ on white is the safe floor.

3. Tracking pixels before consent

GA4 or Plausible in `app/layout.tsx` fires on every page load. For any EU user this is a clear ePrivacy 5(3) violation. Gate behind a consent state with default-off. Or — the cleanest fix — switch to cookie-less first-party analytics (Plausible self-hosted, Fathom, or Simple Analytics) and skip consent banners entirely.

4. Supabase RLS policies

Lovable often sets up Supabase tables with overly permissive policies — `auth.uid() IS NOT NULL` lets any authenticated user read every row in the table. Audit each table; lock policies to `auth.uid() = user_id` (or similar) so users only see their own data. This isn't a legal-compliance issue per se, but it's adjacent to GDPR's data-minimization requirements and CCPA's reasonable-security requirement.

5. Secrets in the client bundle

Run a quick bundle search for `sk_` (Stripe), `service_role` (Supabase service role JWT), `AKIA` (AWS access keys), `xoxp-` (Slack tokens). Anything that should be server-only must not be in `NEXT_PUBLIC_*` env vars. Move the calling code behind a server-side route handler and read the secret server-side.

6. AI-generated legal copy

If Lovable wrote your privacy policy, terms of service, or marketing claims, read every line carefully. AI-generated legal text commonly cites laws inaccurately ("under California law…"), makes claims your app can't actually deliver ("end-to-end encrypted"), or asserts qualifications the operator doesn't have ("HIPAA-compliant"). These create separate exposure — false advertising claims under FTC §5 or state little-FTC statutes.

7. Bundle copyleft contamination

Lovable's underlying AI can reproduce code from its training data, including from AGPL- or GPL-licensed projects. If your bundle contains AGPL fingerprints, you may have a publish-source obligation simply by deploying the app as a network service. Cheap to scan, expensive to discover at acquisition diligence.

How to fix all of these in one pass

Run a Comply Code scan on your Lovable URL — it automatically catches items 1, 2, 3, 5, and 7. Items 4 (RLS) and 6 (legal copy) need a manual review. Each fix is typically 5–30 minutes of work. The scanner emits paste-into-Cursor / paste-into-Lovable fix prompts that apply the change for you. Total time to remediate a typical Lovable app: 2–4 hours, mostly waiting for redeploy and re-scan.