From Lovable demo to production: a checklist

1. Is every table protected by row-level security?

Lovable apps typically use Supabase, where the browser talks to the database directly with a public key. That is safe only if every table has row-level security (RLS) enabled and policies that say who may read and write each row. A table without it can be read by anyone who opens the browser’s developer tools.

• Enable RLS on every table in the public schema — including the ones you think nothing reads.
• Write policies per operation (select, insert, update, delete), tied to auth.uid() or the user’s organization.
• Test them as two different users: one must not see or change the other’s rows.
• Check storage buckets too — uploaded files are often public to anyone with the URL.

2. Is any secret key in the browser?

The Supabase anon key is meant to be public. The service_role key bypasses every access rule and must only ever run on a server. Search the built JavaScript, not just the source, for any key that isn’t meant to be public: Stripe secret keys, OpenAI or Anthropic keys, email-provider keys. If one is there, move the call into a server function and rotate the key — once it has shipped, assume it has been copied.

3. Does authentication hold up outside the happy path?

• Password reset works end to end, and the link expires.
• Sessions end on sign-out on every device you expect them to.
• Admin-only actions are refused by the server for non-admins — hiding a button is not access control.
• Email confirmation is on if accounts should belong to a real address.

4. Do payments reconcile, including refunds and failures?

A demo proves that a card can be charged. Production needs your database to agree with Stripe afterwards, whatever happens:

• Webhooks verify Stripe’s signature, so nobody can post a fake “payment succeeded”.
• Handlers are idempotent: Stripe retries, and a retried event must not create a second order or subscription.
• Cancellations, refunds, failed renewals and disputes update your records, not just successful payments.
• Prices come from the server or Stripe — never from a value the browser sends.

5. Will you know when something breaks?

If the first you hear of an outage is a customer email, you have no monitoring. Add error tracking for both the browser and the server, an uptime check on the pages that matter, and alerts that reach a person. Then break something on purpose and confirm the alert arrives.

6. Could you restore yesterday’s data?

Check which backups your database plan actually includes and how far back they go. Then restore one into a separate project and look at the data. A backup that has never been restored is a hope. Also keep staging and production separate, so a test run can never write to live data.

7. Can you undo a bad deploy?

• Every change to the database schema is a migration in the repository, not a click in a dashboard.
• Environment variables are set per environment and documented.
• You know how to roll back to the previous version, and you’ve done it once.

Going to the App Store or Google Play too?

A web app wrapped for mobile has its own list: current SDK requirements for both stores, privacy details and data-safety answers that match what the app actually sends, push notifications and deep links tested on real devices, and enough native value to pass Apple’s minimum-functionality guideline. That is covered in our store launch service.

What next?

Work through the list in order — the first two items matter most. If you find more than you want to fix yourself, the AI-Built App Audit Report checks all of it, and twenty failure modes besides, with read-only access. The full list is in the 20 ways AI-built apps fail in production.