Apps built with AI
How to take a Lovable, Bolt or v0 app to production
Short answer: move the code to a repository you own, close the security gaps, split staging from production, add a way to see errors and restore data, and only then decide whether to harden what exists or rebuild it in stages.
Written by Matheus PavaneliPublished Oct 10, 2026Reviewed Oct 10, 20263 minHouse method
Download as Markdown0 of 4 checked
Mark each check as you go. Nothing is saved.
What breaks when real users arrive
A generated app is built to show the idea. Real users bring what it skipped: data rules, payments that must not run twice, emails that must arrive, and a bill that grows with every request. None of this shows in a demo, all of it shows in the first month.
1. Put the code in a repository you own
While the code lives only inside the builder, nobody else can review it, test it or deploy it without the builder.
Check it yourself
Check whether your project is connected to a GitHub repository in your own account, not a shared one.
Fix it
Export or sync the project to a repository in your name, and make every later change go through it.
2. Close the security gaps first
Exposed tables and leaked keys are the failures that cost the most and arrive first.
Check it yourself
Run the four Supabase checks of the guide on data leaks: row level security, the service role key, redirects and staging.
Fix it
Fix row level security and the service role key before anything else; they decide who can read your users' data.
3. Split staging from production
Every change tested against production risks real data, and every secret in the code ships to the browser.
Check it yourself
List where each environment points: database, payment keys, email sender. If staging and production share one, they are not apart.
Fix it
Create a staging project, keep secrets in environment variables of each one, and deploy to staging before production.
4. See errors and know how to restore data
Without error tracking you learn about failures from customers, and without a tested backup a bad change is permanent.
Check it yourself
Ask two questions: where would I see an error a user hit an hour ago, and when did I last restore a backup to a copy?
Fix it
Turn on error tracking and database backups, then restore one backup to a copy once, so you know it works.
Harden or rebuild
Harden when the data model fits the product and most screens only need fixes. Rebuild in stages when every new feature breaks an old one, when the data model fights the product, or when the builder's limits block what users ask for. In both cases the work happens one stage at a time, with the app staying live.
Questions
Do I have to leave the builder?
Not on day one. The code moves to your repository first; the builder can keep generating screens while the risky parts move into reviewed code.
How long does the diagnosis take?
The discovery week ends in a written plan by stage, with what ships, by when and for how much. If you stop there, the plan is yours.