Is your Lovable app ready for real users? Run this before you find out the hard way.

You built it on Lovable. It works when you click through it. Now you are deciding whether to put it in front of paying strangers, and the honest answer is that clicking through it yourself proves almost nothing — you hold a logged-in session, a warm cache, and the muscle memory to avoid every path that breaks.

The good news: production-readiness is testable, most of it in one afternoon, and most of it without an engineer. Below is the checklist we run at the start of every rescue, turned around — the things we get called about after launch, checked before it. Every item is a test with a pass or a fail, not an opinion.

Money — because this is the one you cannot walk back

• Make one real payment with a real card on the production URL, then find the matching row in your database. Not the Stripe dashboard — your database. If the money is in Stripe and the record is nowhere, stop here.
• Open your payment provider's webhook page. There should be a production endpoint, and its recent deliveries should show succeeded — not failing, not retrying, not empty.
• Refund that test payment and check what your app does. Many generated apps record the charge and never hear about the refund, which means the customer keeps access you think you revoked.

If any of the three fails, the payments piece needs the full trace — checkout session, payment intent, webhook signature, idempotency key, database write. We wrote that trace up separately, and it is the first thing we run on a rescue.

Identity — sign up as a stranger, not as yourself

• Open a private browser window and sign up on the production domain with an email you have never used. The most common launch-day failure is an OAuth or magic-link allowlist that still only knows the preview domain.
• Click the magic link or verification email from a phone, on mobile data. Links that resolve on your laptop's session can dead-end on a device that has never seen the app.
• Run the password reset end to end. It is the flow nobody tests and everybody eventually needs.

Data — is the database actually private?

• Check row-level security is enabled on every table in Supabase, with a policy — a table with RLS off is readable by anyone holding your public anon key, which is everyone, because it ships in the page.
• From that same private window, take the anon key out of the network tab and request one of your tables with curl. You should get nothing back that a stranger should not see.
• Check your storage buckets the same way. Uploaded files default to guessable public URLs more often than tables do.

Secrets — view source, search, rotate

• Load the production app, view page source, and search for sk_live, service_role and api_key. Any hit is a credential in public. Rotate it today and move the call it powered to the server.

When it breaks, will you know?

• Cause a deliberate error — a bad URL parameter, a form with junk in it — and ask: did anything record that? If the answer is no, your first bug report will come from a customer, worded angrily, days after the bug started.
• Know where your server logs are and open them once before launch day. Finding the logs during the incident doubles the incident.

Environment — the configuration production never got

• List every external service the app touches: database, auth, payments, email, storage. For each: which URL does it call back to, and which keys does production hold? Any answer containing the word preview is a live bug.
• Send yourself the transactional emails — sign-up confirmation, receipt — and look at the from address and where they landed. Unverified sending domains go to spam quietly.

Scoring it

Fourteen checks. A pass on all of them does not make the app bulletproof — it makes it honest: the failure modes that remain are the rare ones, not the ones that were sitting in plain sight. A fail on money, identity or data is a launch blocker; fix it before marketing spends a rupee or a dollar sending people in. A fail on logging or email is a fast follow — days, not months.

And the split that saves you money if something did fail: the screens Lovable generated are almost always fine. Spend on the parts that hold money, identity and records, and leave the rest as generated until it earns a rewrite. If the app already broke and you are reading this after the fact, start with the production-failures guide instead.

If you want a second pair of eyes

The first audit is free. Send the live URL and we run this list plus the payment trace against your app, and return written findings within 48 hours — what passed, what failed, what it costs to fix. The findings are yours either way; there is nothing stopping you taking them to another engineer.