Taking a Lovable or Bolt App to Production: A Security Checklist

Before an app built with Lovable, Bolt, Replit, v0 or Cursor goes live, you need to lock down four things: secrets (no private keys in the browser), database access (Row Level Security on every table), authorization (checked on the server, not just hidden in the UI) and anything that costs money (payments, AI calls and email, verified and rate-limited). Then add monitoring and backups so you find out about problems before your customers do.

AI app builders are genuinely impressive at getting you from idea to working demo. But "it works when I click through it" and "it's safe with real users and real data" are different bars. The gaps tend to be the same from app to app, which is good news: they're fixable, usually without a rewrite.

This is the checklist we work through when we review an AI-built app.

Why "it works in preview" isn't the same as production

In preview, there's one user (you), test data, and nobody trying to break anything. In production, you have many users who must never see each other's data, real payment and personal information, and bots probing every endpoint. AI-generated code is usually written to make the feature work, not to defend it. The fixes below close that gap.

1. Secrets and API keys

• No private keys in the frontend. Anything shipped to the browser can be read by anyone. Search your client code for keys to Stripe, OpenAI, email providers and admin database access.
• Keep the Supabase service_role key on the server only. The anon (public) key is designed to be in the browser, but it's only safe when Row Level Security is on (see below). The service_role key bypasses all of that and must never reach the client.
• Rotate any key that was ever committed or pasted into a prompt. Assume it's been seen.
• Separate keys for development and production, stored as environment variables in your hosting platform, not in the code.

2. Database access rules (Row Level Security)

This is the most common serious problem in AI-built apps. If you use Supabase, every table that holds user data needs Row Level Security enabled and policies that limit who can read and write each row.

alter table public.projects enable row level security;

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

create policy "Users can create their own projects"
on public.projects for insert
with check (auth.uid() = user_id);

• RLS is enabled on every table in the public schema.
• Each table has policies for the actions users actually need (select, insert, update, delete), and nothing broader.
• You've tested as two different users and confirmed neither can see or change the other's data.
• Storage buckets have access rules too, not just tables.

Firebase has the same idea under a different name (security rules). Either way, "the app only shows users their own data" is not protection. The database itself must refuse.

3. Authentication and authorization

• Check permissions on the server. Hiding an "Admin" button in the UI doesn't stop someone from calling the admin API directly.
• Don't trust roles or IDs sent from the browser. Read the user's identity from their verified session on the server.
• Protect every API route and edge function, not just the pages.
• Turn on email verification and sensible password rules, and test the password-reset flow end to end.

4. Anything that costs money

• Payments: calculate prices on the server and verify webhook signatures (for example, Stripe's signing secret). Never trust an amount sent from the browser.
• AI calls: put OpenAI, Anthropic and similar calls behind your own server endpoint, with per-user rate limits and a monthly spending cap at the provider.
• Email and SMS: rate-limit anything that sends messages, or bots will use your form to send spam at your expense.
• Billing alerts on your hosting, database and AI accounts.

5. Inputs and APIs

• Validate input on the server, not only in the form.
• Lock CORS to your own domains.
• Check file uploads for type and size, and store them outside your public web root.

6. Deployment and environments

• Separate development and production databases, so testing never touches real customer data.
• All environment variables set in production. Missing or wrongly scoped variables are the most common reason an app works in preview and breaks after deploy.
• Custom domain with HTTPS, and redirects from any old URLs.

7. Monitoring, backups and recovery

• Error logging so you see crashes before customers report them.
• Uptime monitoring with alerts that reach a person.
• Automated backups, and a restore you've actually tested. A backup you've never restored is a hope, not a plan.

8. Code health

• Update dependencies and check them for known vulnerabilities (for example, npm audit).
• Tests on the critical paths: sign-up, login, checkout and anything involving money or permissions.
• Remove dead code and unused features the AI generated along the way.
• Write down how it works: where it's hosted, which services it uses, and how to deploy. Future you (or your next developer) will need it.

What you can do yourself vs. when to bring in an engineer

A confident builder can usually handle moving keys into environment variables, locking CORS, turning on email verification and adding pagination. Row Level Security policies, server-side authorization, payment webhooks and setting up separate environments are where most founders want an experienced engineer, because a mistake there exposes real data.

Fix or rebuild?

Most AI-built apps have a solid core. In most reviews, the right answer is to fix the risky parts, keep what works, and add tests and monitoring, not to start over. A rebuild only makes sense when the data model is fundamentally wrong or every fix breaks two other things.

Get a second set of eyes

Our AI-built app rescue service starts with a code and security review: we go through the codebase, infrastructure and data access, and give you a prioritized report in plain English, whether or not you hire us for the fixes. We work with Next.js, React, Supabase, Firebase, Node, Laravel and WordPress, and we build our own security tooling for AI-generated code, Aegis.

Send us the repo and tell us where it's stuck. If you're earlier on and deciding what to build at all, start with what to automate first.