Your Lovable or Claude-Built App Is Not Production Ready Yet: The Checklist

You built the app in Lovable, Bolt, Replit or Claude Code. It works. You can sign up, log in, click through, and the data saves. Now you want real customers in it.

The gap between "it works" and "it is safe to launch" is usually four things. None of them are visible from using the app. You can check all four in about an hour.

1. Check your Supabase row level security policies#

This is the one that leaks customer data.

Supabase exposes your Postgres database straight to the browser. The only thing between a logged-in user and every row in your database is row level security. If RLS is off, or the policy is permissive, anyone with an account can read everyone else's records using the browser dev tools.

List every unprotected table:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public' and rowsecurity = false;

Then find policies that are technically on but allow everything:

select tablename, policyname, cmd, qual
from pg_policies
where schemaname = 'public';

A qual of true permits every row. Same as no policy, written to look like one.

A correct policy for a table where each row belongs to one user:

alter table public.projects enable row level security;

create policy "owner reads own projects"
  on public.projects for select
  using (auth.uid() = user_id);

create policy "owner writes own projects"
  on public.projects for insert
  with check (auth.uid() = user_id);

select, insert, update and delete each need their own policy. The common AI-generated mistake is a correct select policy with update and delete left open, so users read only their own rows but can delete anybody's.

Test it. Make two accounts. Logged in as the second, try to read the first one's data in the browser console:

const { data } = await supabase.from('projects').select('*').eq('id', 'other-users-id');

An empty array is correct. A returned row means your policy does not work.

2. Find the API keys you published to the internet#

Everything in your frontend bundle is public. The browser downloaded it.

Supabase gives you two keys. The anon key is meant to be public and is fine in the browser, provided RLS actually works. The service_role key bypasses RLS completely and must never reach the browser.

Open your deployed site, open DevTools, go to Sources, and search all files for service_role, sk-, and anything named SECRET. In Next.js and Vite, any variable prefixed NEXT_PUBLIC_ or VITE_ is deliberately bundled into the browser, so a secret with one of those prefixes is public.

If you find one, rotate it. Changing the code is not enough, since the old key is in your git history.

3. Add server-side validation behind every UI check#

AI builders put validation in the form. The form runs in the browser, and the browser belongs to the user. Anyone can skip your form and call the API directly.

For every write in your app, ask whether the server would notice a request with different values:

• Can a request set a price to zero or a negative number?
• Can a user send role: "admin" in a profile update and have it saved?
• Can a user create a record pointing at someone else's id?

That third one catches people constantly. If profiles has a role column and users can update their own profile row, they can promote themselves to admin. Move roles to a table users cannot write to.

4. Get a deploy and a backup you have tested#

Pushing to main should deploy. The test is whether someone other than you could ship a one-line fix today.

Supabase gives daily backups on paid plans. Free projects get no point-in-time recovery and pause after a week of inactivity. If the app holds customer data, pay for the plan and restore the backup once to a scratch project so you know it works.

Add Sentry or similar. Twenty minutes, and without it the only way you learn a page is broken is a customer telling you.

Why your AI coding assistant keeps breaking things it fixed#

Two causes. There are no tests, so nothing catches the regression. And the context window cannot hold your whole codebase, so the assistant rewrites functions without seeing what calls them.

Add tests around whatever keeps breaking, and split large files. Stopping to add tests feels like going backwards and is almost always faster.

The one hour version#

1. Run the two SQL queries. Fix any table with RLS off or a policy of true.
2. Search your deployed bundle for service_role and sk-. Rotate anything you find.
3. Make a second account and try to read the first one's data. It should fail.
4. Check whether a user can change their own role or a price.
5. Turn on backups and confirm you can deploy from a clean push.

When to hire a developer instead#

Some of this is worth paying for rather than learning under deadline:

• The app already holds real customer data, particularly health, financial or identity data
• An enterprise buyer has sent you a security questionnaire
• Payments are involved and amounts are set anywhere the user can reach
• Auth needs rebuilding rather than patching
• Your remaining-work estimate keeps growing instead of shrinking

What to search for. The useful terms are "Supabase security audit", "Lovable developer", "Next.js Supabase developer", or "take AI-built MVP to production". A full-stack developer who has not worked with Supabase RLS specifically will spend your money learning it.

What it costs. A review runs around $150 to $400. A review plus the fixes runs around $800 to $1,500. Three days to two weeks, depending on how much data the app already holds.

What you almost never need is a rewrite. The generated code is ordinary React, TypeScript and Postgres, and it is repairable. What usually needs replacing is the authorisation layer and anything touching money. That is days, not months.

Get it checked#

We do this as a fixed-scope hardening pass: audit, written findings, then the fixes. Backend engineering covers the auth and data model work and cloud and DevOps covers deploys and backups. The SaaS customer portal case study shows a multi-tenant app with the permissions done properly.

Still pricing the build? How much it costs to build an MVP covers what to budget, including this pass.