Is my Lovable app safe to launch? The checks I run before saying yes

Every week someone sends me a Lovable link with the same message: "It works. Is it safe to launch?"

Usually the app does work. That's the frustrating part. The screens render, sign-up goes through, the Stripe test card gets accepted. Nothing about the experience tells you whether a stranger can read your customers table with a single HTTP request. Most of the time nobody has checked, because the tool never asked them to.

Here's what I look at, in the order I look at it. You can run most of this yourself in an afternoon.

1. Can the public read your database?

Lovable apps sit on Supabase. Supabase ships a "publishable" (anon) key that is meant to be in the browser. The thing that stops that key from reading everything is row-level security, and RLS is where AI-generated builds go wrong most often.

Take the anon key from your Supabase project settings and try to read a table you would never want public:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

If that returns rows, anyone on the internet can do the same. Repeat for orders, messages, subscriptions, whatever holds something you'd be embarrassed to leak. An empty array [] is what you want to see when you're not logged in.

Then check the tables themselves. In the SQL editor:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

Anything showing false is wide open to whoever holds the anon key, which is everyone who has opened your site. I wrote a longer piece on the RLS mistakes that show up again and again if you want to go deeper here.

2. Which keys are in the bundle?

Open the live site, open DevTools, go to Sources, and search across all files for eyJ. That's how every Supabase JWT begins. Paste each hit into a JWT decoder and look at the role claim. anon is fine. service_role means the key that bypasses every security rule you have is sitting in public JavaScript.

Also search for sk_live, sk-, and re_. Stripe secret keys, OpenAI keys and Resend keys have no business in a browser bundle, and I've seen all three end up there because the AI "fixed" a 401 by moving the call client-side. More on where keys hide and how to rotate them.

3. Does auth actually gate anything?

This is different from "is there a login page". A lot of generated apps protect routes in React, which only hides the UI. The API underneath still answers to anyone.

Two things to try. First, log out, then paste the URL of a page that should require login. If the data flashes before the redirect, the fetch happened before the guard. Second, log in as user A, note the id of one of your records in the URL or the network tab, then log in as user B and request it directly. If B gets A's record, your RLS policies check that a user is logged in but not which user.

Also look at the email settings. Lovable projects often ship with "Confirm email" turned off in Supabase because it made testing faster. That means anyone can sign up as ceo@yourbiggestclient.com without owning the inbox.

4. Does Stripe reconcile?

The usual pattern I find: the success page reads session_id from the URL and sets is_pro = true on the user. No webhook. Anyone who can guess the success URL becomes a paying customer, and anyone whose card fails next month stays one forever.

Go to the Stripe dashboard, Developers, Webhooks. If there's no endpoint pointing at your production domain, subscriptions are not being tracked. If there is one, click it and look at the recent deliveries. A column of red 4xx or 5xx responses means the endpoint exists but nothing is landing. I go into the specific failure modes in a separate post on Stripe integrations that don't reconcile.

5. Can you deploy it again tomorrow?

Find the repository. If the only copy of the code lives inside the tool, you don't own the product yet; you rent it. Lovable can sync to GitHub, and you should turn that on before anything else.

Then the boring checks that nobody does until it's too late: is there a database backup you have actually restored once? Are the production and preview environments using different Supabase projects, or is your preview build pointing at live customer data? Is the custom domain on your account or someone else's?

What I do when a founder sends me a link

I ask for read-only access to the repo and the Supabase project, sign an NDA if they want one, and go through the list above plus a few dozen smaller things. It takes a couple of days. The output is a ranked list: what would cause a breach, what would cause an outage, what would just annoy a future developer.

Most apps come out somewhere in the middle. A few RLS policies that say true, one key that needs rotating, a webhook that was never wired. Fixable in a week. Occasionally an app comes out clean, and I say so.

The tools aren't the villain here. Lovable and Bolt do something genuinely impressive. They just optimise for the demo, and the demo never includes a stranger with curl.

If you'd rather have someone else run the checks, that's what the AI App Launch Audit is. If you'd rather do it yourself, start with the curl command at the top. It takes thirty seconds and it answers the question people are actually asking.