Lovable app not working in production? The seven things that break, and how to fix them

The prototype worked. You shared the preview link, people loved it, you connected a domain, and then the support emails started. Here is what is usually going on.

1. The database is open

Lovable scaffolds Supabase tables quickly, and row-level security is often off or permissive. The interface hides other people's rows; the database doesn't. Anyone with the browser's developer tools and your public key can read everything. Fix: a policy on every table that has user data, tested with a real user's token, not the service key.

2. Stripe takes money and forgets to stop

Checkout works, so money comes in. Then a card fails or someone cancels, and a webhook arrives that nobody wrote a handler for. People keep paid access for free, or paying customers get locked out. Fix: handlers for invoice.payment_failed, customer.subscription.deleted and charge.refunded, plus a nightly reconciliation against Stripe.

3. OAuth redirects still point at the preview domain

Sign in with Google works on the preview URL and fails on yours. Fix: add the production domain to the provider's allowed redirect URLs and to Supabase's site URL, then test in a private window.

4. Environment variables that never made it to production

Keys that lived in the preview environment are missing on the real deploy, so a feature silently returns nothing. Fix: a checklist of every variable the app reads, verified on the production host before launch.

5. Emails go to spam or nowhere

Transactional email is sent from a default sender with no domain verification. Fix: a verified sending domain in Resend or Postmark, and templates for the four emails that matter: welcome, receipt, reset, and failed payment.

6. It works with ten records and dies at five hundred users

No indexes, queries that fetch everything, and effects that fire twice. Fix: indexes on every foreign key and filter column, pagination on every list, and a load test before you tell anyone.

7. Every fix breaks something else

Without tests or architectural memory, each prompt undoes a previous one and the credit meter runs. Fix: stop prompting for a day, get a written verdict on the codebase, then decide between finishing it and rebuilding it with the prototype as the spec.

When to bring in a developer

If two or more of the above are true, the cheapest next step is a 48-hour written verdict from someone who has shipped production software, with a fixed price to fix it. At JetBuild that starts at $2,000 for an audit with the critical fixes done, and you keep the report either way.