You have a Lovable app that a handful of people use every week. Maybe it’s ten pilot customers, maybe it’s your own sales team. Someone has asked what it costs, and now you’re wondering whether this thing can take paying customers or whether you need to start over with “real” developers.
Founders tend to ask us that as a yes-or-no question. It rarely is one. In most AI-built apps we review, some parts are fine as they are, some need reworking and a few need writing again properly. We helped a client build their CRM with Lovable, and the speed it gave them was real. The work that comes after is deciding which parts of that speed to keep.
This article covers how we sort an MVP into those three piles and the setup we put around it for launch. The security checks themselves are in our pre-launch checklist for Lovable, Bolt and Replit apps, so we won’t repeat them here.
Read the code before anyone says “rebuild”
The rebuild-or-not question gets decided far too often from a demo. Someone clicks around, finds a bug or two, and the verdict is that it all has to go. A demo can’t tell you that. The code and the database can.
When we take on an AI-built app as part of our prototype-to-production work, the first week is a review that ends in a written fix list. We read the database schema and its access policies, look at where secrets and API keys are kept, count how many components do nearly the same job, and check what the app does when a request fails. The GitHub history helps too: an app built in small, steady steps is a very different thing to take over than one that has been regenerated from scratch five times.
It also helps to know what you’re standing on. According to Lovable’s own docs, projects created since May 2026 use TanStack Start, older ones use React and Vite, and the database is PostgreSQL, either through Lovable’s built-in backend or a Supabase project you connect. All of that is mainstream, and any React developer can work with it.
Keep, refactor, rebuild
The keep pile is usually bigger than people expect. The screens are often the best part of a Lovable app, because that’s what the founder spent most of their prompts on. The database and sign-in hold up fine at launch scale. There’s no reason to move off them just because they were set up by a builder. The flows themselves are worth keeping too: they encode months of decisions about what users actually need.
The refactor pile is for things that are the right idea but were never meant to meet strangers. Access policies are the big one. Next comes the schema: generated tables often store things as free text or JSON that should be proper columns, and they skip foreign keys and indexes until something gets slow. Any call to OpenAI, Stripe or another paid API made from the browser has to move to a server function. And most generated apps have three slightly different versions of the same table or modal, which makes every later change cost three times as much.
The rebuild pile is short, but it matters. A Stripe checkout button is easy to generate. What comes after is harder: updating the subscription when a card fails, a customer cancels or changes plan, and coping when Stripe sends the same event twice, which its docs say can happen. The same goes for separating customers from each other once you sell to more than one company (we wrote up how to build multi-tenant SaaS separately), for scheduled work that has to run when nobody has the app open, and for integrations that need to retry when the other side is down.
When a rebuild really is the better option
Sometimes it is. We’d recommend starting again when the data model is wrong at the root, for example when everything lives in one table of JSON blobs and every screen parses it differently. Another case is an app regenerated so many times that the same rule exists in five places and nobody can say which one runs. The third is a product that has changed so much since the MVP that the code describes a different business.
Even then, the Lovable version is a useful thing to have. It’s a working specification. Developers can click through it, see the flows and ask “like this, but…” instead of working from a written brief.
The setup around a launch
Staging and production need separate databases. While you were prototyping, test sign-ups and real customers probably shared one, which is fine until somebody runs a cleanup on the wrong rows. Make sure the production database sits in an account your company owns, and that you know how to export it.
The code should live in your company’s GitHub, and changes to production should go through a branch and a review. Hosting can stay on Lovable with your own domain, or move to Vercel or Netlify when you want more control over builds and environments.
Billing switches to live mode, with access granted by the webhook, never by the page the customer lands on after paying. Stripe’s test clocks let you fast-forward a subscription through renewals and failed payments before a real customer hits them.
Email needs the least glamorous fix of all. Password resets and invoices should come from your own domain, with SPF and DKIM set up, or a good share of them will land in spam on day one.
Finally, monitoring and backups. Error tracking tells you about a broken page before a customer does. Supabase takes daily backups on its Pro plan and above, keeping seven days on Pro. Check which plan you’re on, and restore a backup once before launch so you know it works.
Can you keep building in Lovable after launch?
Yes, and many teams do. Lovable syncs with a GitHub repository in both directions, so a founder can keep adjusting screens in Lovable while developers work in the same repo. What changes is the route to customers: every change lands on staging first, someone checks it, and only then does it go live.
The order we’d do it in
- Review the code and database, and write the fix list.
- Close the data-access gaps and move secrets and paid API calls off the browser.
- Set up staging and production, connect GitHub, agree how changes get to production.
- Rebuild billing around webhooks and test it with Stripe test clocks.
- Set up email on your domain, error tracking, uptime alerts and backups, and test a restore.
- Open it to your pilot customers first, then to public sign-ups.
How long that takes depends entirely on what the review finds, which is why we give a fixed-scope estimate after the review rather than before it.
Mistakes we see
Sources
Questions we often hear
Do we have to stop using Lovable to launch?
No. Lovable syncs with GitHub in both directions, so you can keep making changes there while developers handle billing, integrations and anything complex. The only rule is that changes go through staging before customers see them.
Can a Lovable app handle paying customers?
Yes, once data access, billing, email and monitoring are sorted. The stack underneath, React and PostgreSQL, runs plenty of production SaaS. The risk is in what was generated without review, not in the tools.
Should we move from Lovable’s database to our own?
What matters is that the production database sits in an account your company controls, with backups you’ve tested and a way to export it. If that’s true today, there’s no rush to move.
How long does it take to go from MVP to launch?
It depends on what the code review finds. After the first week you get a written fix list and a fixed-scope estimate for the work.
Can you work on code Lovable generated?
Yes. We start by reading it and tell you plainly what to keep, what to fix and what to rewrite.
