How to take a Lovable app to production

Why Lovable apps stall before production

Lovable gets you from an idea to a working, published app faster than anything else I have used. The gaps show up later, when real people start signing up, paying and poking at things you never tested.

It helps to know what Lovable actually built for you. Projects created from 13 May 2026 run on TanStack Start: pages render on the server and publish as a Cloudflare Worker. Older projects are React and Vite single-page apps that render in the browser and publish as static files. Behind either one sits a PostgreSQL database, either Lovable's built-in backend (database, login and file storage, managed for you) or a Supabase project you connected yourself.

That is a sensible stack. The problems are rarely the stack. They come from how the app was assembled:

• Access rules live in the database, and nobody wrote them carefully. Whether user B can read user A's data is decided by row level security rules on each table. Lovable's own security docs say misconfigured rules are a common cause of data leaks. The app can look perfect while those rules let everyone through.
• The security scans are a floor, not a ceiling. The Quick scan runs every time you publish and covers a fixed set of checks. The Deep scan, which looks at your app's own logic, permissions and payments, only runs when you ask for it. Lovable says plainly that its tools cannot guarantee complete security and suggests a professional review for apps handling sensitive data.
• Each prompt fixes the thing in front of it. Lovable edits what you describe. It does not stop to ask whether that change breaks sign-up on a different screen, so the app drifts.
• The preview is not the live site. Publishing in Lovable creates a snapshot. Your edits don't reach the live app until you publish again, so it is easy to test one version and ship another.

How the common failures show up in Lovable

I keep a general list of the ten things that break most often in AI-built apps. In Lovable apps they have a particular shape. Here is the version of that checklist I would run on a Lovable project before letting real users in.

Auth and data access

Lovable sets up login quickly. The weak point is authorisation: what each signed-in user is allowed to see and change. The per-table rules are what stand between one customer and another customer's data, and the Deep scan also checks whether your server code respects them. I look for tables with no rules, rules that only check "is this person logged in", and admin features hidden in the interface but not blocked in the database.

Secrets and Edge Functions

Lovable's docs are right that API keys can't be kept safe in front-end code. It spots keys pasted into chat, points you to its Secrets store, and typically moves calls that need them into server code. The risk is older keys that slipped through before that happened, and server functions that hold a key correctly but never check who is calling them. A server function that sends emails or calls a paid AI service for anyone who asks is a bill waiting to happen.

Payments

Lovable offers its own built-in payments on paid plans, or you can connect your own Stripe account. Either way, the moment that matters is how your app finds out a payment succeeded. If it upgrades the user when a success page loads, closed tabs and failed renewals will leave your records out of step with what people paid. Cancellations and refunds often have no handling at all.

Publishing, domains and limits

Publishing to a lovable.app address is free on every plan. A custom domain needs a paid plan. Lovable's plans don't cap visitors or bandwidth, but on the Free plan newer apps are limited to 1,000 server requests per project every 10 seconds, after which visitors see a temporary unavailable page. Your database has its own capacity, set by its instance size. For most launches, none of this is the bottleneck. A slow query on a table with no index usually is.

How export to GitHub works

This matters if anyone other than Lovable is going to touch the code, including me. Lovable's Git sync is two-way: changes in Lovable push to GitHub, and changes pushed to the active branch sync back into Lovable. A few details catch people out:

• Connecting always creates a new repository. You can't link an existing one, and reconnecting after a disconnect creates another new repository.
• Lovable works on one branch at a time, normally main. If a push clashes with branch protection rules, Lovable pushes to a branch called lovable-sync for someone to merge by hand.
• The database is not in the repository. The code includes migration files that describe its structure, but the data is exported separately, and that export leaves out stored files, Edge Function code and secrets.
• A .zip download of the code is available on paid plans. It is a one-off snapshot and won't stay in sync.

Two-way sync is good news for a rescue: a developer can fix code in GitHub and you can keep prompting in Lovable. The catch is that your next prompt can undo a fix without either of you noticing.

Scaling and leaving Lovable

You can host a Lovable app elsewhere, and Lovable is clear that you aren't locked in. It is more work than it sounds. A TanStack Start app needs a host that runs server code. Moving the database alone doesn't move login, file storage, realtime or Edge Functions, and AI features and connectors keep running through Lovable until you replace them. The supported destinations are managed or self-hosted Supabase. Anything else means rebuilding those pieces yourself.

My honest view: most founders don't need to leave Lovable's hosting to launch. Fix the access rules, payments and error handling first. Move only when you have a specific reason.

What a fix looks like

The aim is a Lovable app you can put in front of paying users, that you can keep editing in Lovable afterwards. Security and data first, money second, experience third.

1. 1

   Free health check

   Run the vibe-code health check for a first read on where the app stands.

2. 2

   Call and repository access

   A short call about who uses the app and what it must do. You add me to the GitHub repository Lovable created, and I review the code, the database rules and the backend settings.

3. 3

   Fixed price, in writing

   A list of what I will fix, in order, with one price. If parts are better rebuilt, I say so now, not halfway through.

4. 4

   Access rules, keys and payments

   Row level security on every table, Edge Functions that check the caller, rotated keys, and payment handling that does not rely on a page load.

5. 5

   Errors, mobile, accessibility and polish

   Real empty, loading and error states, a phone-first pass, keyboard and screen reader basics, and consistent components.

6. 6

   Tests, publish and handover

   Tests on sign-up, payment and the core journey. You publish the fixed version, and get notes on which parts to leave alone when prompting.

A Rescue Sprint usually takes about a week. The price is fixed and agreed in writing after the free health check and a call, not before, because two Lovable apps that look alike can be very different underneath. If you want to see where yours stands first, run the free health check.

When a rebuild makes more sense

I would rather tell you a rescue is the wrong call than sell you one. With Lovable apps, a rebuild is usually the better route when:

• You need to leave Lovable entirely and the app leans on the built-in backend for login, storage and AI features. Replacing each of those can cost as much as building it cleanly.
• The data model is wrong at the root. For example, a marketplace built as if there were only one kind of user. That touches every table and every screen.
• The product has changed. If half the screens belong to an idea you have dropped, you are paying to fix code you don't need.
• A team will take it over. Developers you hire, or investors doing due diligence, will want a conventional codebase they can read without a guide.

In those cases your Lovable app is still valuable. It is the clearest brief you could write. An MVP Build starts from £12,000 and takes 4 to 6 weeks, designed and built by me in Next.js, TypeScript, Postgres and Stripe, with every account in your name. If you are still weighing up tools, the Lovable vs Bolt vs designer comparison covers that choice, and the FindPopups case study shows a marketplace I built and run myself.