A Pre-Launch Audit for Apps Built With Lovable or Bolt

AI app builders such as Lovable and Bolt are very good at producing something that looks finished. The screens render, the buttons click, the demo data appears. What they cannot tell you is whether the app is safe to put in front of strangers. That gap is where most launches go wrong, so this guide walks through an audit you can run yourself, in order, before you share the link with anyone outside your team.

Get the code and look for secrets

Step 1: Get the code out of the builder

You cannot audit what you cannot read. Most of these tools can sync or export the project to a Git repository, so do that first and work on a local clone:

git clone <your-repo-url> app-audit
cd app-audit
npm ci
npm run build

If npm ci fails because there is no lockfile, or npm run build fails outright, write that down as finding number one. A project that only builds inside the builder's environment is a deployment risk waiting to happen.

While the dependencies install, open package.json and note the framework (Vite, Next.js, something else), the backend client libraries (Supabase, Firebase, a custom API) and any payment or email SDKs. That list tells you which of the following steps matter most.

Step 2: Search for secrets in the client bundle

Anything that ships to the browser is public. In a Vite project, variables prefixed with VITE_ are embedded into the built JavaScript; in Next.js, the same is true of NEXT_PUBLIC_. That is fine for a Supabase anon key or a publishable payment key, and a serious problem for anything else.

Search both the source and the build output:

grep -rnE "sk_live|sk_test|service_role|secret|api[_-]?key" src/ dist/ .next/ 2>/dev/null
git log -p | grep -nE "sk_live|service_role" | head

The second command matters because a key deleted from the current code still lives in the repository history. Any secret you find in either place should be treated as leaked: rotate it at the provider, then move the call that needs it to the server side.

Test access and break the flows

Step 3: Test data access as an outsider

Generated apps often enforce permissions only in the user interface. The page hides the "edit" button from other users, but the database will happily accept the request anyway. To check this, open the app in a private window, sign up as a second test user, and use the browser's network tab to replay requests that read or modify the first user's records.

If the backend is Supabase, confirm that row level security is enabled on every table in the public schema and that each table has policies that actually reference auth.uid(). A table with RLS disabled, or with a policy of using (true), is readable by anyone holding the anon key, which is everyone who loads your site.

Step 4: Walk the critical paths with bad input

Make a short list of the flows that touch money, accounts or other people's data: sign-up, password reset, checkout, invitations, file upload. For each one, try the unhappy paths deliberately:

1. Submit forms with empty fields, very long strings and unexpected characters.
2. Use the back button and refresh in the middle of multi-step flows.
3. Open the same flow in two tabs and complete both.
4. Let a session expire, then try to save something.
5. Upload a file type the app did not expect.

You are looking for crashes, duplicate records, silent data loss and error messages that leak stack traces or query details. Record each issue with the exact steps to reproduce it.

Step 5: Check the production basics

A surprising number of AI-built apps are still wired to development settings when they launch. Go through this short list:

• Environment variables for production are set in the hosting dashboard, not hard-coded.
• Authentication redirect URLs include the real domain, not only the preview URL.
• Payment webhooks point at the production endpoint and verify signatures.
• Error tracking or at least server logs are switched on, so you will know when something breaks.
• npm audit has been run and anything critical in direct dependencies is understood.

Run Lighthouse in Chrome DevTools against the deployed preview as well. You are not chasing a perfect score; you are looking for obvious problems such as multi-megabyte images or a blank page until all scripts load.

When the audit finds more than you can fix

The honest outcome of this exercise is usually a list: a few items you can fix in an afternoon and a few that need someone who has done this before, typically authentication, database policies, payments or deployment. That list is valuable in itself, because it turns a vague "make it production ready" request into concrete, testable tasks.

If you decide to bring in help, you can post those items as a job on Workli, where finishing software built with tools like Lovable, Bolt, Replit, v0 and Cursor is one of the hiring categories, and proposals break the work into milestones with delivery dates. Whoever you hire, hand them the audit notes and reproduction steps from this guide rather than a general description; it will save both of you time.

An audit like this takes a few hours, and it is far cheaper than discovering the same problems after real users have trusted the app with their data. Run it once before launch, keep the checklist, and run it again whenever the builder regenerates a large part of the codebase.