Taking your Lovable app to production: what "production ready" means and a stage-by-stage checklist

What "production ready" actually means

A demo has to work once, for you. A production app has to keep working for strangers, on a bad day: when someone tries to read another user’s data, when a payment arrives twice, when the database needs restoring, or when you ship a change that breaks sign-in. Production ready means you have an answer for each of those situations before it happens, not after.

In practice that comes down to seven areas: who can see which data, how people sign in, how money moves, where your data lives and how you get it back, how you test changes without touching live users, how you find out something broke, and how your public pages show up in search.

Data security: row level security comes first

Lovable apps that store data use Supabase, either through Lovable Cloud or your own Supabase project. Supabase is explicit about the risk: a table in an exposed schema without row level security (RLS) is readable and writable by any role with a grant on it, so RLS has to be enabled on every table in that schema. Enabling it is not enough on its own: each table also needs policies that say, for example, that a user can only read the rows they own.

The service role key bypasses RLS entirely, so it must stay on the server and never reach the browser. As of September 2026, Lovable runs a quick security scan before you publish (database access rules, dependency vulnerabilities) and offers an on-demand deep scan that reviews access control, unauthenticated endpoints, leaked secrets and payment flows. Use both, but take Lovable at its word: its docs say these tools cannot guarantee complete security, and you remain responsible for what your app needs.

Sign-in and emails

Sign-in usually breaks at two moments. The first is when you move to your own domain: if your app uses your own Supabase project, you have to add the new domain to the allowed redirect URLs yourself (and in Google Cloud Console if Google sign-in uses your own credentials); on Lovable Cloud, Lovable adds it when the domain goes live.

The second is when sign-ups pick up. On your own Supabase project, the built-in email sender for sign-up and password recovery is limited to 2 emails an hour as of September 2026, which is why Supabase’s production checklist recommends your own SMTP provider. The same checklist recommends turning on email confirmations and keeping one-time codes valid for an hour or less.

Payments and webhooks

When you connect your own Stripe account, Lovable stores the secret key as a backend secret and calls Stripe from edge functions, so the key never appears in your code. By default it skips webhooks and asks Stripe for the payment status instead; if you fulfil orders or run subscriptions, you will want webhooks. Two details from Lovable’s docs matter when you go live: the preview has no separate test environment, so with a live key, payments made from the preview are real; and product and price IDs differ between test and live mode, so they need recreating.

Stripe’s own webhook guidance is the checklist for the rest: verify the signature on every event, return a 2xx response quickly, expect the same event more than once (keep a record of processed event IDs), and never rely on events arriving in order. In live mode Stripe retries failed deliveries for up to three days, so a broken endpoint can go unnoticed for a while.

Data model and backups

On Lovable Cloud, Lovable runs daily backups and restores them from its dashboard. On your own Supabase project, backups depend on your plan: as of September 2026, Pro projects get daily backups kept for 7 days, Team 14 days and Enterprise up to 30, while Free projects get none and Supabase recommends exporting your data regularly with the CLI. Point-in-time recovery is a paid add-on. Supabase also recommends moving off the Free plan so an inactive project is not paused.

Backups only help if the data inside them makes sense. Before you have hundreds of users, check that each table has a clear owner column, that the fields you filter on are indexed, and that deleting a user does not leave orphaned rows behind. Changing the data model is cheap now and expensive later.

Staging: the preview is not a separate environment

Lovable describes the preview as your app’s staging environment, but its docs add the part that catches people out: the preview and the published app share the same backend and data, so changes to your database affect both. Testing a destructive migration or a new payment flow in the preview is testing it on your live users.

Once real users depend on the app, the safe setup is a second backend (a separate Supabase project with test data) that you point a copy of the app at, or a workflow in GitHub where changes are tested before they reach the live project.

Own domain, monitoring and SEO

Connecting your own domain on Lovable requires a paid plan as of September 2026. Once it is live, set up two kinds of monitoring that do not depend on you noticing: an uptime check that alerts you when the app stops responding, and error tracking that tells you when users hit a broken page or a failed function.

For the marketing pages, how search engines read them depends on when the app was created. Apps created since May 13, 2026 use TanStack Start and render full HTML on the server. Older React and Vite apps are single-page apps, and Lovable serves a pre-rendered version only to verified crawlers on its own hosting. Either way, Lovable recommends verifying the domain in Google Search Console and submitting your sitemap; after that, titles, descriptions, content and speed still decide how each page appears.

Stage 1: before you invite real users

Do these while the only data in the app is yours:

1. RLS enabled on every table, with a policy per table that you can explain in one sentence.
2. No service role key or other secret in the frontend code; run the Lovable deep scan and fix what it finds.
3. Your own domain connected, with sign-in tested on it end to end.
4. Email confirmations on and your own SMTP provider if you are on your own Supabase project.
5. A privacy policy that matches what you actually collect.

Stage 2: before you take money

Payments add a second system that has to agree with yours:

1. Live Stripe key, live products and prices, and one real purchase made on the published app.
2. Webhooks with signature verification and duplicate handling for anything you fulfil automatically.
3. Backups you have restored at least once, on a plan that keeps them long enough.
4. A separate test backend, so payment changes never get tried on live data.

Stage 3: before you grow

These matter once the app is something people rely on:

1. Uptime and error monitoring that alerts someone other than your users.
2. Indexes on the queries that run most, checked against real data.
3. Search Console verified and a sitemap submitted for the public pages.
4. Code synced to a GitHub repository in your account, and every service (domain, database, Stripe, email) registered in your name.

Stay on Lovable or migrate?

Staying is reasonable if Lovable Cloud covers your needs and you are comfortable with its hosting, backups and credit-based billing. You can keep building in Lovable and still harden the app. Migrating, fully or in part, makes sense when you need the database in an account you control with your own keys, a real staging environment, a developer working outside Lovable without the sync, or costs that are lower when you pay each service directly.

Be realistic about the effort. Lovable says there is no automatic migration between Lovable Cloud and your own Supabase project in either direction: the data has to be exported and the schema rebuilt. And apps created since May 13, 2026 need hosting that runs server code, not a static file host.

What to look for when you hire help

Whether you search for a Lovable developer, an agency or a freelancer, a few questions sort the good ones quickly:

• They ask to look at the app before quoting, and give you a written list of what is wrong and what is fine.
• They quote a fixed scope with a clear price, not an open-ended number of hours.
• They can explain RLS policies, webhook handling and your backup plan in plain words.
• They set up every account in your name, or tell you in writing which ones stay in theirs and how they hand them over.
• They tell you when something does not need fixing. Not every app needs a rewrite.

What I do at Omplia

I take apps built with Lovable, Bolt, v0 or Replit to production on your own domain, with the code in your GitHub and the domain in your name, and the database, email and payments in your own accounts. Hosting stays in my account while you have a care plan; if you leave, I move it to yours. On the way I handle data security, sign-in, payments, backups and monitoring. I start by checking your link for free and telling you in writing what is worth changing and what is not. If what you have on Lovable is enough, I will say so.

An app starts from 2,900 €, or from 4,900 € if it moves off the platform, plus an optional monthly care plan from 190 €/month. VAT not included. These are starting prices: the final one depends on scope and I confirm it in writing before we start.