# How to take a Lovable, Bolt or v0 app to production

Canonical URL: https://thorfyn.com/en/notes/lovable-bolt-v0-app-to-production

> What breaks when an AI-built app meets real users, the order to fix it in, and how to tell when rebuilding costs less than hardening what exists.

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.

- House method
- Written by Matheus Pavaneli (https://thorfyn.com/en/about)
- Published Oct 10, 2026
- Reviewed Oct 10, 2026
- 3 min

## 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.

## 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.

## 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.

## 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.

## 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.

## Sources

- [Lovable, Connect to Supabase](https://docs.lovable.dev/integrations/supabase)
- [Supabase, Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security)

## Get the plan before the code

The discovery week ends in a plan by stage for your app, with a fixed price for each stage.

- See the Discovery: https://thorfyn.com/en/discovery
- Next note: https://thorfyn.com/en/notes/bubble-to-code-migration
- Questions and requests: hello@thorfyn.com
- Back to the home page: https://thorfyn.com/en