How to make a Lovable, Bolt or Replit app production-ready A 12-step checklist before real users and payments

The short answer: to make an app built with Lovable, Bolt or Replit production-ready, get the code into your own repository, lock down who can read and write each table, move every secret key to the server, verify payments on the server, separate test data from live data, set up backups and error alerts, and test the whole thing as two different users before real customers arrive. The 12 steps below cover each one, with the exact setting or test to run.

This matters more every month. Lovable made its chat free to use on September 24, 2026 (Lovable), and on October 8, 2026 The Pragmatic Engineer described tech companies building internal Lovable-style platforms so that non-engineers can create applications (The Pragmatic Engineer). More apps are being built by people who have never had to secure one.

Methodology: this is an editorial guide, not a survey of apps. Every product behavior and figure below was checked against the linked vendor documentation or report on October 23, 2026. Builder features change quickly, so confirm settings in your tool's current docs.

Demo vs production: what actually changes

A demo has one user (you), fake data and no money moving. Production has strangers, some of them curious or hostile, real personal data and real payments. That changes what "working" means.

The risks are not hypothetical. In February 2026, a single exam app built with an AI app builder exposed 18,697 user records through 16 flaws, 6 of them critical, including missing Row Level Security and inverted access logic (The Register). Lovable said that the app's builder had been given a security scan before publishing but had not acted on its recommendations. More broadly, Veracode's 2026 report found AI-generated code passed its security tests only 56 percent of the time (Veracode, July 28, 2026).

The 12-step production checklist

Work through these in order. The first six protect your users' data and money; the rest keep the app running once people depend on it.

1. Get the code into a repository you control

Before changing anything, make sure you own a copy. Lovable syncs a project two ways with one GitHub repository, but only one branch at a time, and paid plans can also download the code directly (Lovable docs). Bolt lets you download a zipped copy of a project and manage versions through GitHub (Bolt Help Center). With a repository you get a history of every change, a way back if a fix breaks something, and the option to hand the code to a developer later.

2. Run the builder's own security scan, and read the results

Lovable and Bolt both ship scanners, and they are worth running before anything else. (The rest of this checklist works as a manual review for any builder, including Replit.)

• Lovable runs a Quick Scan automatically every time you publish, covering database access rules and Row Level Security, known vulnerabilities in npm dependencies and exposed MCP server authentication. A Deep Scan, which you start yourself, reviews the code for authorization flaws, abusable endpoints, injection, leaked secrets, payment and billing problems and exposed personal data (Lovable docs).
• Bolt offers a project security audit from the Publish menu on paid plans, which reviews code and database and fixes what it can, plus a database security check on all plans. The audit lists anything it can't fix under action items for you, and you can run up to 30 audits a day (Bolt Help Center).

The scan is only useful if someone acts on it. According to Lovable, that is where the February incident went wrong. Treat every finding as a task, and remember Lovable's own wording: its tools "do not replace a thorough security review."

3. Turn on Row Level Security for every table

Supabase is a common backend for these apps: Lovable can create a Supabase project for you (added October 20, 2026), and Bolt can connect to Supabase or move its built-in database into your own Supabase account (Lovable changelog; Bolt Help Center). Supabase's rule is blunt: enable RLS on every table in an exposed schema, because "a table in an exposed schema without RLS is readable and writable by any role with a grant on it" (Supabase docs). Once RLS is on, no rows come back through the API with the publishable key until you write policies that allow them.

A typical policy that lets signed-in users read only their own orders looks like this:

alter table public.orders enable row level security;

create policy "Users read their own orders"
  on public.orders for select
  to authenticated
  using ((select auth.uid()) = user_id);

Write a separate policy for each action (select, insert, update, delete) a role genuinely needs, and none for the rest. Supabase also advises that on projects which still grant the anon and authenticated roles access by default, you revoke those grants, because adding policies alone does not remove them.

4. Keep secret keys on the server

Supabase has two kinds of key. The publishable key (formerly anon) is designed to be visible in a web page or app, but RLS "decides what this client can reach". The secret key (formerly service_role) bypasses RLS entirely and should only be used in backend code such as Edge Functions; Supabase says never to use it in the browser (Supabase docs). The same goes for Stripe secret keys, email provider keys and AI API keys.

Search the code for each key's prefix and for words like secret and service_role. If a secret key was ever in client code, or pasted into the builder's chat, rotate it at the provider, not just in the code. Lovable detects API keys pasted into the project chat; Bolt keeps them in a secrets setting that its server functions read, so they never reach users' browsers (Bolt Help Center).

5. Enforce sign-in on the server, not just the screen

Hiding a page in the interface does not protect it. Every protected action has to check who the user is where the data lives: in RLS policies or in server functions. Also confirm that signing out really ends the session, that email verification and password rules are switched on, and that error messages don't reveal whether an email address has an account. Bolt's security audit lists these same sign-in and session checks, which makes its documentation a good manual checklist too.

6. Move prices, credits and limits to the server

If the browser sends the price, the browser can change the price. Anything with value (prices, discounts, credits, usage limits, single-use codes, admin flags) must be calculated or checked on the server. Bolt's audit explicitly looks for ways users could change a price, skip a required step or claim the same single-use item twice.

7. Confirm payments with signed webhooks

Don't unlock paid features because the checkout page redirected back to your app. Unlock them when your server receives the payment event from the provider. With Stripe, that means verifying each webhook against the Stripe-Signature header and your endpoint's signing secret, using the raw request body. Stripe also notes that endpoints can receive the same event more than once, so log the event IDs you have processed and skip repeats (Stripe docs).

8. Separate test data from live data, and plan schema changes

Replit gives each app a development database for building and a production database for the published app, and applies structural changes from development to production when you publish. Its docs warn that removing columns still used in code, incompatible type changes, required fields without defaults and renames can break the live app, and recommend testing in a deployment preview first (Replit docs). Lovable started recording each Cloud database structure change as a Drizzle migration file on October 7, 2026 (Lovable changelog). Whatever the tool, keep a written history of database changes and never test with real customer data.

9. Set up backups before you need them

Check your database plan. Supabase provides daily backups only on paid plans: 7 days on Pro, 14 on Team and up to 30 on Enterprise. Point-in-time recovery is a paid add-on. On the Free plan there are no automatic backups, and Supabase recommends exporting data regularly with the CLI and keeping off-site copies (Supabase docs):

supabase db dump --db-url "$DATABASE_URL" -f backup.sql

Then try restoring a backup into a spare project once. A backup you have never restored is a hope, not a plan.

10. Log errors and get alerted

OWASP's 2025 Top 10 lists "Security Logging and Alerting Failures" and "Mishandling of Exceptional Conditions" alongside the better-known risks; its number one is still Broken Access Control (OWASP). In practice: send front-end and server errors to an error-tracking service, watch the database and function logs your platform provides, and make sure a failed payment webhook or a crashed function reaches someone's inbox.

11. Put limits on usage and spend

A public app can be hammered by bots or by one enthusiastic user, and AI features cost money per call. Add rate limits to forms and AI endpoints, set billing alerts at every provider you pay, and use the builder's own controls. Lovable, for example, added workspace credit usage limits and alerts on October 7, 2026, plus warnings when a Cloud database is under high load.

12. Finish the launch basics

Connect your own domain, confirm HTTPS, send transactional email from your own domain through a proper email provider so it doesn't land in spam, and add a privacy policy that matches the data you actually collect. If the app is going to the App Store or Google Play, budget for the store requirements and fees covered in our guide to what it costs to build an app in 2026.

A 30-minute test you can run yourself

You don't need to be a developer to catch the most damaging problem. Run these checks on your own app only.

1. Two-account test. Create two accounts, A and B. As A, create some private data (an order, a note, a profile). Sign in as B and try to reach it: change IDs in the address bar, open A's links, search for A's content. B should see nothing.
2. Signed-out test. Open the app in a private window without signing in and try the same links.
3. Direct API test. With your project URL and publishable key (both are in the app's code), ask Supabase for a table directly. If RLS is doing its job, you get an empty list or an error, not your customers' rows:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/orders?select=*" \
  -H "apikey: YOUR_PUBLISHABLE_KEY"

4. Price test. Start a checkout and look at what the browser sends (the network tab in your browser's developer tools). If the amount is in the request and the server trusts it, fix step 6.
5. Key search. In the browser's developer tools, search the loaded scripts for service_role, sk_live and secret. Nothing secret should appear.

If any of these fail, stop sending traffic to the app until it's fixed, and rotate any key that was exposed.

Harden it or rebuild it?

An app from these tools can often be hardened: the checklist above is about configuration, server-side checks and operations, not starting over. A rebuild is worth considering in a few specific situations.

A prototype still has value in a rebuild: it is a working specification that users have already clicked through, which makes the next version faster to scope.

What it costs to get help

Our AI App Rescue starts from $990: we review an app built with Lovable, Bolt, Replit or Cursor, run a security audit of logins, database rules and API keys, fix what we find and launch it safely to production. The final price depends on how many tables, roles, integrations and payment flows the app has, so send us the app link and a description of what it does, and we'll send you a fixed written quote. If a rebuild is the better route, these are our published starting prices:

• Starter App from $3,000: a simple app on our premium template with premium screens, login, a database, a full security audit (of the new app we build, not a review of an existing one) and publishing to both app stores.
• Web App / SaaS MVP from $12,000: dashboards, portals and SaaS products.
• Mobile App MVP from $15,000: iOS and Android from one codebase.

"From" means the smallest sensible version; a quote rises with scope. The full list is on our pricing page, and new customers get 20% off the first project.

FAQ

Is a Lovable, Bolt or Replit app secure enough for real customers?

It can be, but not by default. Lovable and Bolt both ship security scans, and Lovable's own documentation says those tools cannot guarantee complete security and do not replace a thorough security review. Before real customer data or payments go in, check data access rules on every table, keep secret keys on the server and test the app with two separate accounts.

Is the Supabase anon or publishable key safe to have in my app?

Yes, Supabase designs the publishable (formerly anon) key to be visible in browsers and apps, but only when Row Level Security is enabled on every table in an exposed schema. Without RLS, anyone with that key can read and write any table the anon role has been granted access to. The secret (formerly service_role) key bypasses RLS and must never reach the browser.

Do I need to rebuild my AI-built app from scratch?

Not necessarily. If the data model is sound and the problems are access rules, keys and missing operations work such as backups and monitoring, hardening the existing code is usually enough. A rebuild makes sense when the data model is wrong for the business, the code cannot be exported, or every fix breaks something else.

Does the free Supabase plan back up my database?

No. According to Supabase's documentation, daily backups are included on the Pro (7 days), Team (14 days) and Enterprise (up to 30 days) plans. Free plan projects are advised to export their data regularly with the Supabase CLI db dump command and keep off-site backups.

Planning a new app instead? Read how much it costs to build an app in 2026, see our full price list, or browse projects we've built.

Sources

1. Lovable docs: Security (Quick Scan, Deep Scan, responsibility statement), checked October 23, 2026
2. Lovable docs: GitHub integration
3. Lovable changelog (October 7 and October 20, 2026 entries)
4. Lovable: You can now chat with Lovable for free (September 24, 2026)
5. Bolt Help Center: Check your project's security
6. Bolt Help Center: Advanced database settings
7. Bolt Help Center: Database secrets settings
8. Bolt Help Center: Backups, restore, and version history
9. Replit docs: Production databases
10. Supabase docs: Row Level Security
11. Supabase docs: Understanding API keys
12. Supabase docs: Database backups
13. Stripe docs: Receive Stripe events in your webhook endpoint
14. OWASP Top 10:2025
15. The Register: report on a Lovable-built app's vulnerabilities (February 27, 2026)
16. Veracode: 2026 GenAI Code Security Report (July 28, 2026)
17. The Pragmatic Engineer: The Pulse, new trend of building internal vibe-coding apps (October 8, 2026)

VLWritten by the VL Studio team. We build apps, automations, AI receptionists and websites for small businesses and founders in the US and Europe.