Lovable App Rescue

What Goes Wrong With Lovable Apps in Production

Lovable's own documentation and community forums acknowledge most of these failure modes. They are not product defects — they are the predictable result of a tool optimised for rapid prototype delivery being pushed into a production environment with different requirements.

Supabase Row Level Security errors

Lovable builds on Supabase by default. RLS policies control which users can read, write, or delete which rows in the database. When these policies are misconfigured — which is the documented failure mode in CVE-2025-48757, affecting more than 170 Lovable-built applications — the consequences are severe: either your users cannot access their own data, or all data in the table is visible to any authenticated user.

The AI cannot reliably self-audit RLS configuration because the correct policy depends on your specific data model and access requirements, not on general patterns. Human review is required.

Auth flows that break under custom domains

Lovable's preview environment runs your application under a shared Lovable subdomain. OAuth redirect URIs, magic link callbacks, and JWT refresh token flows are all configured against this subdomain. When you switch to a custom domain — either directly or via Vercel — these flows break in ways that are not visible until a real user attempts to authenticate. Email confirmation links point at the old domain. OAuth providers reject the new redirect URI. Sessions expire and cannot be refreshed.

Stripe integration failures

Stripe in Lovable-built applications regularly presents two specific failure modes: the application is still running in Stripe test mode when it is deployed to production (live payments never process), and Stripe webhooks are configured against the wrong URL (payment confirmation events never reach the application, leaving orders in a permanently pending state). Both are invisible from the user's side until a customer attempts to pay.

Vercel deployment errors

Lovable exports to GitHub; deployment typically targets Vercel. Common failure points: environment variables present in the Lovable environment are not carried across to Vercel's environment variable settings (causing runtime errors on every API call); the build output directory is set incorrectly (causing a successful build that serves an empty page); Vercel's Edge Runtime limitations cause server-side functions to fail silently.

Secrets in client-accessible code

Lovable applications built before the developer is aware of the NEXT_PUBLIC_ prefix convention in Next.js frequently expose API keys to the browser. Any key prefixed NEXT_PUBLIC_ is included in the client-side JavaScript bundle and is accessible to anyone who inspects the page source. Supabase anon keys, Stripe publishable keys, and third-party API keys are the most commonly exposed.

UK GDPR and Lovable Applications

If your Lovable application collects personal data — user registrations, email addresses, usage data, payment information — UK GDPR applies from the moment the first real user interacts with it. Lovable does not configure consent mechanisms, privacy policies, or lawful basis documentation. These are not optional: they are requirements before you can lawfully market a product to UK users.

For applications handling financial data (FCA consideration), health data (ICO, CQC, Caldicott), or data belonging to legal clients (SRA consideration), the regulatory overlay is more complex. Our diagnostic includes a UK regulatory awareness review as standard for all applications handling personal data.