Lovable to production ready: what breaks, what to fix first, and a checklist

Taking a Lovable app to production ready means closing the gaps a prototype can live with but real users cannot: every database table locked down with Row Level Security, no secret keys shipped to the browser, server-side checks on anything that touches money or personal data, payments confirmed by webhooks, and backups and alerts switched on. In most cases this is hardening, not a rewrite.

The order matters more than the length of the list. Fix data exposure first, then secrets, then payments, then everything that keeps the app running. Below you will find that order, a checklist you can work through, the GDPR points that matter for UK and EU users, what running the app live costs, and an honest view of when to keep prompting and when to bring in engineers.

What production ready means for a Lovable app

A demo works when you click through it. A production app keeps working when strangers use it in ways you did not plan. A useful test is four questions:

• Can a second user, logged in with their own account, see or change your data? The answer must be no.
• Can someone who opens the browser's developer tools find a key that lets them do more than a normal user? Again, no.
• If a payment fails, is retried or is faked, does your database still tell the truth?
• If the app breaks at 2 a.m., will you know before your users tell you?

If you cannot answer all four with confidence, the app is not ready for real users, however polished it looks.

The failures that show up first

The most common problem is not exotic. It is a database that anyone can read. A researcher scanned 1,645 apps from Lovable's public showcase and found 170 with Supabase tables readable using only the public key, a flaw tracked as CVE-2025-48757. The public key is meant to be public; the protection is supposed to come from Row Level Security policies on each table.

That protection is often missing. One security write-up states that Lovable creates tables without enabling Row Level Security or creating policies, and calls missing RLS the number one Lovable security flaw. Whether or not your project followed that pattern, you have to check every table yourself.

The other usual suspects:

• Secrets in the front end. Payment, email or AI keys placed in client code end up in the bundle anyone can download.
• Validation only in the browser. A form that checks a price or a role in the browser can be bypassed with a single edited request.
• No rate limits. Sign-up, login and any endpoint that calls a paid API can be hammered until your bill or your inbox explodes.
• One environment. Testing changes directly on the live database is how real data gets deleted.

Triage order: what to fix first

Published checklists range from a nine-fix senior engineer's list covering server-side secrets, RLS, real auth, CORS, rate limits, CI/CD, observability and database scaling, to a 47-point list across nine areas and a 12-check list before real users arrive. They overlap heavily. What they rarely give is an order. Work by risk:

The hardening checklist

Database and authorisation

• Turn on Row Level Security for every table, including ones you think are unused.
• Write policies that tie each row to its owner (for example, a user can read only rows where the owner ID matches their own).
• Test with two real accounts: log in as user B and try to load user A's records by changing IDs in the URL or the request.
• Check storage buckets for uploaded files the same way; they have their own access rules.
• Keep admin actions behind a role check on the server, not a hidden button.

Secrets and server-side logic

• Search the codebase for anything that looks like a secret key. Move each one into server-side functions or environment variables.
• Rotate any key that was ever in client code, even briefly. Assume it was copied.
• Recalculate prices, totals and permissions on the server. Never trust a value the browser sends.
• Restrict CORS to your own domain.

Payments

• Grant access only when a webhook from your payment provider confirms the payment, not when the user lands on a success page.
• Verify webhook signatures and make handlers safe to run twice.
• Test failed cards, refunds and cancelled subscriptions. European cards often trigger an extra authentication step under Strong Customer Authentication, so test that flow too.

Environments and deployment

• Create a separate staging project with its own database and keys.
• Put the code in a Git repository you control, so changes are tracked and reversible.
• Run database changes as migrations, tested on staging before live.

Backups, monitoring and limits

• Confirm backups exist and, more importantly, practise a restore.
• Add error tracking and uptime alerts that reach your phone.
• Rate-limit login, sign-up, password reset and any endpoint that calls a paid service.
• Log who did what on sensitive actions, without logging passwords or card data.

GDPR and UK GDPR for European users

If your users are in the UK or EU, personal data rules apply from the first sign-up. The practical points:

• Data location. Check which region your database project runs in. Choosing an EU or London region makes your data-transfer story much simpler.
• Processor agreements. Every service that handles your users' data (database, hosting, email, payments, analytics, AI) is a processor. Sign or accept their data processing agreements and list them in your privacy policy.
• Privacy policy and cookies. Say what you collect, why and for how long. Non-essential cookies and trackers need consent first under PECR in the UK and the ePrivacy rules in the EU.
• User rights. Make sure you can export and delete a user's data on request, including uploaded files, and state how long backups keep it.
• Breach readiness. The RLS gap above is exactly the kind of incident that can trigger notification duties. Fixing it is also a compliance step.

This is not legal advice; for regulated sectors such as health or finance, speak to a specialist.

Running costs after launch

As of November 2026, Lovable has a free plan, and paid plans start at $25/month for Pro with 100 credits, with a Business tier above it; every plan includes 20 Cloud credits a month to host the backend, and custom domains need a paid plan. The free plan gives 5 daily credits, capped at 30 per month, and it shows a Lovable badge on your app, with no credit rollover or top-ups; Pro adds custom domains, badge removal, rollover and top-ups.

For a live app, budget for more than the builder: a paid plan for the domain and badge, database and hosting usage as traffic grows, a domain name, email sending, error tracking and payment fees. Prices on these pages are in US dollars, so UK and EU buyers should allow for currency conversion and check whether VAT is added at checkout.

Fixing it yourself or handing it to engineers

You can keep prompting your way through much of the checklist if you can read the generated code, run the two-account test and understand why a policy works. Prompting alone is risky when the tool says it has fixed something and you have no way to verify it.

Bring in engineers when any of these is true:

• You handle health, financial or children's data.
• You take payments or run subscriptions.
• You have found one RLS or secrets problem and are not sure how many more exist.
• Investors, a corporate client or a procurement team will ask security questions.
• You need to own and move the code without being tied to one tool.

If you prefer a known cost to an open-ended agency bill, NOWWWA Studio builds production software with senior engineers and the NOWWWA agent system. A Fixed-Price MVP is €8,000, agreed upfront, ships in about two weeks, and you own all of the code. For ongoing work, the Build Subscription is €4,000, billed every two weeks. If you want to see the direction before committing, the Fast Prototype starts with a €99 deposit that comes off the build price. Booking a call to walk through your Lovable app is the simplest way to find out which route fits.