Stuck at 80% in Lovable? How to take a Lovable and Supabase app to production

You usually don't need a rewrite. A Lovable app that works in the demo is missing the parts nobody sees: database rules, checks on the server, payments confirmed by webhooks, a deploy you can repeat, error tracking, and code a person can change without the AI undoing it. All of that can be added to the app you already have. Here is what the last 20% is made of, in the order I work through it.

Why the last 20% is the hard part

Lovable is very good at the first 80%: screens, flows, a Supabase database and sign-in, built about as fast as you can describe them. The last 20% is different work. It is mostly about what happens when things go wrong: a stranger calls your database directly, a payment fails halfway, two people edit the same row, a prompt rewrites a file that was working.

That is also where prompting stops helping. Each fix touches more files, the AI loses track of what the earlier fixes did, and you go round in circles. That loop is the signal to stop and look at the app as a whole, not to write a longer prompt.

What production-ready means for a Lovable app

1. 01Every table has the right rulesRow-level security is on for every table, and each policy matches who should see what. My Supabase security checklist has the checks and the SQL.
2. 02Secrets stay on the serverAI keys, the Stripe secret key and the Supabase service role key live in Edge Functions or another server, never in the browser. Here is how to check.
3. 03Money moves on the serverAn order becomes "paid" because a signed Stripe webhook said so, and handling the same webhook twice changes nothing. A success page in the browser proves nothing.
4. 04Errors reach you firstError tracking on the front end and in Edge Functions, so you hear about a failure before a user emails you about it.
5. 05Deploys you can repeatThe code in GitHub, a second Supabase project for staging, and database changes kept as migration files in the repo rather than clicks in the dashboard.
6. 06Google can see the public pagesA single-page React app sends search engines an almost empty page. The fixes are here.
7. 07Someone else can change itThe biggest files split up, types on everything that touches money and sign-in, and a short README that says how the app fits together.

Do you have to leave Lovable?

Not necessarily. Lovable can sync the project to a GitHub repository, and what's in that repository is ordinary React, Vite and Supabase code. A developer can work in the repository while you keep prompting in Lovable, as long as you agree who changes what.

What I suggest: keep Lovable for screens and copy, and move the parts that must not break (database migrations, Edge Functions, payments) to changes that are reviewed in git before they go live. If the AI later rewrites one of those files, the review is where you catch it.

How a Lovable code audit works

An audit is the quickest way to know what the last 20% is for your app. Mine is $500 – $1,500, fixed by the size of the app, with a written report in 3 to 5 days. I need read access to the GitHub repository and the Supabase project, and a test account on the live app. I sign an NDA before you share anything, if you want one.

• Database rules read against who should see what, then tested from outside the app, the way a stranger would.
• Every key: where it lives, who can read it, what it can do.
• Sign-in, payments and the main flow followed end to end, including the ways they fail.
• Deploys, environments and error tracking.
• Speed on a mid-range phone, and what Google sees.

You get every finding ranked by risk, with what to do about it and a rough estimate in hours. The sample report shows the format on a made-up app.

Hiring a developer to fix a Lovable app

Whoever you hire, these questions sort the people who'll fix your app from the ones who'll start again:

• Have they set up row-level security in Supabase before, and can they explain a policy in plain words?
• Will they start from the app you have? A rewrite should be a conclusion, not where they begin.
• Is the price fixed before they start, or open-ended by the hour?
• Will they leave notes, so you can keep prompting without undoing their work?
• Will they work on staging first, and sign an NDA before getting access?

If you'd like that to be me, here is how I take AI-built apps to production. The first call is free, and if your app needs something I don't do, I'll say so on the call.