How to test a Lovable, Bolt or Replit app before launch

You describe the app, the builder writes it, and the preview works. You sign up, click through the main screens, and everything does what you asked for. The publish button is right there.

The preview tells you less than it seems to. You were the only user, you were logged in, you typed sensible things into every field, and you clicked in the order you had in mind when you wrote the prompt. Real users won't do any of that. Some of them will be on a phone, and a few will go looking for things they shouldn't see.

This guide is for anyone shipping an app built with Lovable, Bolt or Replit, especially if you didn't write the code yourself and don't plan to read all of it. You don't need a QA background. You need about an afternoon, two browser windows and a list. If you're on an engineering team with AI-generated code coming into an existing codebase, our guide to testing AI-generated code is the better fit.

What the builders already check for you

All three platforms have put real work into catching problems before you ship, and it's worth knowing what you get for free.

Lovable's agent can open your app in a browser, click through it, and read console errors and network requests. It also runs a quick security scan on every publish that looks for tables without row-level security, access rules that let everyone in, and known vulnerable dependencies. A deeper scan that reviews your app code is available, but you have to start it yourself.

Bolt has a Security Audit screen in the database settings that flags missing access policies and policies that let anyone read everything, with a button to ask Bolt to fix them.

Replit's Agent has App Testing, where it drives a real browser, clicks through features, and fixes what breaks. Replit also splits your database into development and production, and the Agent can only touch development. That split came after a widely reported incident in July 2025 where an agent deleted a user's production database, and it's a good safeguard.

Use all of it. But notice what these checks have in common: the agent is testing its own work against its own idea of what you wanted. Replit's docs say outright that App Testing's coverage depends on how clearly you describe your critical flows, and it doesn't run after every change. Lovable's security docs say the scans "do not replace a thorough security review." The builders check that the code works. Whether it does the right thing for your users is still on you.

1. Write down what has to work

Before you test anything, open a doc and list the things that would hurt if they broke. Keep it to the flows a real user depends on, in plain language. For a booking app, that might be:

• A new user can sign up, confirm their email and log in
• A logged-in user can book a slot, and it shows up in their bookings
• Two people can't book the same slot
• A user can cancel, and the slot opens up again
• Payment goes through, and a failed card doesn't create a booking
• A user only ever sees their own bookings

Five to ten lines is plenty. This list does two jobs. It's your test plan for today, and it's the thing you'll re-run every time you prompt a big change. Paste it into your builder's project knowledge or instructions too, so the agent's own testing aims at the same flows you care about.

2. Test as a second user

If you only do one thing from this guide, do this one. It's where the most serious problems in AI-built apps show up.

Open your app in a normal window and an incognito window. Sign up as two different users. As user A, create some data: a booking, a note, a profile, whatever your app stores. Then, as user B, try to see it. Look at list pages. Copy the URL of one of A's records and open it in B's window. If the URL has an ID in it, change the number by one and see what loads.

If B can see anything that belongs to A, stop and fix it before you launch. Which fix you need depends on your platform.

Lovable and Bolt (Supabase under the hood)

Lovable and Bolt both build on Supabase, and in a Supabase app the browser talks to the database directly with a public key. That's by design. The only thing stopping one user from reading another user's rows is row-level security (RLS): rules on each table that say who can read and write which rows.

When RLS is missing or too loose, anyone with your public key can read the table, and your public key is sitting in your site's JavaScript for anyone to find. In 2025, a researcher checked 1,645 apps from Lovable's public showcase and found 170 of them exposing data this way, which became CVE-2025-48757. It's a big part of why those built-in scans matter.

Run the built-in scan, then check for yourself. In the Supabase SQL editor (or your builder's database view, if it lets you run SQL), this lists every table with RLS switched off:

select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false;

An empty result doesn't mean you're done. A table can have RLS turned on with a policy that allows everyone, which Bolt's audit flags as "RLS Policy Always True." The two-user test is what tells you the rules actually do what you meant. If you're stuck, a prompt like "Make sure users can only read and edit their own bookings, and add RLS policies for every table" is a reasonable start. Then run the two-user test again. Don't take the agent's word that it's fixed.

Replit (your own server and database)

Replit apps usually have a backend that sits between the browser and the database, so access control lives in your API routes instead of database policies. The question to ask is whether every route that reads or changes a record checks that the logged-in user owns it. Being logged in isn't enough. The two-user test above catches most gaps here too. You can also ask the Agent to list every API route and say which ones check ownership, then spot-check a few of its answers with the second user.

3. Log out and try again

Close every window, open a fresh incognito one, and paste in the URLs of pages that should need a login: the dashboard, a settings page, a specific record. Each one should send you to the login page instead of showing data, even briefly. A page that flashes private content before redirecting is still leaking it.

While you're logged out, try the actions that should need an account. Can you submit the booking form? Post a comment? If the button is hidden but the page still loads, the server-side check might be missing, which is worth a second look.

4. Use the app badly on purpose

AI builders are good at the path you described and less careful about everything around it. Spend twenty minutes being an annoying user:

• Submit every form empty, then with a single space
• Paste a few paragraphs into a field meant for a name
• Use emoji, accented letters and an apostrophe (O'Brien breaks more apps than you'd expect)
• Double-click every submit button. Do you get two bookings, or two charges?
• Hit the back button in the middle of a multi-step flow, then go forward again
• Refresh the page halfway through checkout
• Open the same record in two tabs and edit it in both

Small layout glitches can wait. What you're hunting for is anything that loses data, duplicates it or shows a blank screen. Those are the bugs users email you about.

5. Test payments in test mode, including the failures

If your app takes money through Stripe, make sure you're in test mode and run through the test cards on purpose. 4242 4242 4242 4242 should succeed. 4000 0000 0000 0002 is a declined card, and the user should see a clear message with nothing created on your side. 4000 0025 0000 3155 asks for extra authentication, which is common with European cards and easy for a generated checkout to mishandle.

Then test what happens after the payment. Many apps confirm an order when Stripe sends a webhook to your server, not when the browser comes back from checkout. Pay, then close the tab before the success page loads, and check whether the order still shows up. Do this on the deployed app, because webhooks need a public URL and a builder's preview environment often can't receive them.

6. Test the published app, not the preview

The preview and the live app aren't the same environment, and a lot of launch-day bugs live in the gap between them. Once you publish, go through your list from step 1 again on the real URL. Pay attention to:

• Google sign-in and email confirmation links need your live domain in their allowed redirect URLs. If you added a custom domain, it needs to be there too
• API keys that worked in the preview have to be set for the published app as well
• On Replit, production has its own database, so the test accounts and sample records you made while building won't be there unless you copied them over. Sign up fresh and make sure the empty state looks right
• Open the live link on an actual phone, not just a narrow browser window. Menus should open, forms should work with the on-screen keyboard, and nothing should scroll sideways

7. Re-run your list after every big prompt

Of everything here, this habit pays off the longest. When you ask the agent to fix one thing, it often edits files that other features depend on. The bug you reported gets fixed, and something you tested last week quietly stops working. Nobody notices until a user does.

So before a big prompt, make sure you have a restore point. Lovable and Bolt keep version history and Replit creates checkpoints, so you can roll back if a change goes sideways. After the change, run through your list from step 1 again, and repeat the two-user test whenever the change touched your database, logins or permissions. It's a short routine, and a lot cheaper than finding out from a support email.

When it's time to automate

Clicking through a list by hand works well at launch. It gets old once you're shipping changes every day, and it's easy to skip steps when you're in a hurry. That's usually the sign to turn the list into automated tests that run on their own.

If you're comfortable with code, Lovable and Bolt both sync to GitHub, and you can add end-to-end tests with a framework like Playwright. If you're not, look for a testing tool where you write the flows in plain language and it runs them in a real browser against your live URL. Either way, the list you wrote in step 1 is the hard part, and you've already done it.

qtrl lets you write those flows in plain English and runs them in real browsers against your published app, with screenshots and video of every run. Store each test user's login as an encrypted secret, and your two-user check runs on every release instead of only when you remember. Start with your launch list.