Why deploy is the first hard edge
Lovable's preview is a managed environment: it injects secrets, rewrites OAuth redirects, proxies Stripe, and runs your Supabase queries with a service-role key that bypasses Row Level Security. Every shortcut the preview takes becomes a bug the instant the app leaves it. Industry benchmarks (see our 2026 vibe-coding research) put AI-code vulnerability rates close to half; most only surface after deploy. Below are the seven that surface first, in order.
1. Missing or wrong environment variables
Lovable's preview auto-injects Supabase keys, Stripe keys, and OAuth secrets. Your Vercel deploy doesn't. The first deploy almost always fails at build time with a missing-env error, or at runtime with a silent null fallback that takes the app halfway through a user flow before collapsing.
Fix:enumerate every env var, split preview and production in Vercel, and add a startup assertion that throws if a required key is missing. Don't rely on optional-chaining defaults — they hide configuration bugs until the user hits them.
2. OAuth redirect URIs pointing at localhost or the Lovable preview
Every Lovable rescue we've run has shipped with at least one OAuth provider hard-configured for the preview domain or `localhost:3000`. The sign-in button works on the developer's machine and nowhere else. Users hit a `redirect_uri_mismatch` on first login and churn before the founder finds out.
Fix: pull redirect URIs from an environment variable (`NEXT_PUBLIC_SITE_URL` or equivalent), register every environment (local, preview, production) as an authorised redirect in the OAuth provider, and test the unhappy-path recovery (expired token, revoked access).
3. Stripe webhooks that never run or double-run
The generated Stripe webhook endpoint returns 200 immediately, doesn't verify the signature, and isn't idempotent. When Stripe retries an event — which it does on any non-2xx or timeout — the Stripe benchmark on AI-built integrations found the handler either double-charges, loses state, or drifts from Stripe's source of truth.
Fix: verify the signature, persist every event in an events table with a unique constraint on `event.id`, handle at minimum `checkout.session.completed`, `invoice.payment_failed`, `customer.subscription.updated`, and `customer.subscription.deleted`. See our Stripe-in-Lovable checklist for the full spec.
4. Row Level Security disabled on every table
This is the worst of the seven and the one founders discover last. Lovable's preview uses a service-role Supabase key that bypasses RLS. In production, the client uses the anon key — and without RLS, that means any authenticated user can read every other user's data. The widely-reported February 2026 Lovable/Supabase RLS disclosure captured this exact pattern at scale (see our 2026 research).
Fix: enable RLS on every table, write policies for every read and write path, and verify with a test suite. We walk through this in plain English in Supabase RLS for non-technical founders.
5. Email deliverability — welcome emails in spam, password resets missing
The generated app sends email from an un-authenticated domain, or worse, from Lovable's default sender. Gmail and Outlook dump it into spam; Apple Mail rejects it outright. Founders report a third of pilot users never see their welcome email.
Fix: use a transactional provider (Resend, Postmark), authenticate your sending domain with SPF, DKIM, and DMARC, and test deliverability against a Gmail / Outlook / Apple inbox before launch.
6. Unindexed database queries that get slow at 1,000 rows
Lovable doesn't add database indexes by default. Every query on a non-indexed column is a sequential scan. At 100 rows, unnoticeable. At 10,000, the dashboard takes 1.2 seconds to load. At 100,000, Supabase's connection pool starts timing out.
Fix:run Supabase's query-performance view, find your slowest recurring queries, and add covering indexes for them. Most dashboards recover to sub-100ms with three to five index additions.
7. No rollback path
When deploy #2 breaks deploy #1's working feature — and it will — the founder has no way to revert. There's no staging environment, no migration history (schema changes were made via the Supabase dashboard), and the Lovable preview URL now points at the broken version.
Fix: source of truth in git, schema changes as migrations (Supabase CLI), Vercel preview deploys for every PR, and a written rollback runbook the founder can execute alone. This is the unsexy work that pays back forever.
How many of the seven hit a typical app?
Based on 2026 Afterbuild Labs rescues, across Lovable engagements specifically:
| Failure mode | Rescues hit (%) | Avg severity |
|---|---|---|
| 1. Env vars | ~95% | Low (blocks deploy, visible immediately) |
| 2. OAuth redirects | ~80% | Medium (churn during first-login) |
| 3. Stripe webhooks | ~70% | High (lost revenue, double charges) |
| 4. RLS disabled | ~70% | Critical (data leak, disclosure risk) |
| 5. Email deliverability | ~60% | Medium (silent user loss) |
| 6. Unindexed queries | ~50% | Medium (degrades with scale) |
| 7. No rollback | ~90% | High (turns any incident into an outage) |
What should I do before deploying?
Run the pre-launch audit checklist — it covers all seven. If you're past deploy and already have users, book the free rescue diagnostic; we'll tell you which of the seven you have and what the fixed-fee scope is to close them.