How to test a Lovable app before launch

This guide is for people who built an app with Lovable and are about to show it, share it or sell it. What usually breaks is not the screen you looked at while building: it is what a stranger sees on the published address, with a fresh browser, no session and a different domain. You will get a plan you can follow in one sitting, a fair picture of what Lovable already checks for you, and what a second, independent look adds.

This page is part of a series on testing apps built with AI app builders. If your published app already misbehaves, start with Lovable app not working after publishing.

What Lovable already gives you

Lovable documents three kinds of verification. They are useful, and you should use them while you build.

Browser testing. The agent drives your app in a real browser: it navigates, clicks, fills forms, takes screenshots and captures console logs and network requests. It suits user-visible bugs and multi-step flows. Logging in to test pages behind authentication is supported only when the app uses Lovable's built-in backend (Cloud).
Frontend tests. Vitest, React Testing Library and jsdom tests, stored beside the components, lock in specific UI rules and prevent regressions.
Backend verification. The agent can call an edge function with chosen inputs and inspect the response, and automated edge tests guard business rules and permissions.

Lovable also runs a Quick scan when you open the Publish dialog (database access rules, dependencies, exposed MCP servers), and offers an optional Deep scan on request. Its own documentation says these scans help identify common issues but cannot promise complete security, and that apps handling sensitive data should get an additional professional review.

Most of these tools run only when you ask for them, and they work on your project as the builder sees it.

Where your app lives, and why that matters

Publishing gives each project a lovable.app address, which you can rename in Project settings; paid plans can add a custom domain. The published app is a snapshot: edits stay out of the live site until you click Publish, then Publish changes. A dot on the Publish button signals unpublished updates. So "it works in the editor" and "it works live" are two separate statements, and only the second one matters to your visitors.

Also note that, according to the Lovable database documentation, drafts and the project use the same database as the published app. Test data you create while trying things can end up in front of real users.

Pre-launch test plan for a Lovable app

Publish first, then test the published address, not the editor preview. Open it in a private window.
Check that there is no unpublished change (no dot on the Publish button), so you are testing what you think you are testing.
Load every public page and watch for blank screens, broken images and console errors.
Resize to phone width and check menus, forms and buttons.
Sign up with a new address and confirm the confirmation email arrives and its link opens the published app.
Sign in, sign out, sign in again, and try a wrong password. Check the messages are readable.
Check redirects after sign-in on the lovable.app address and, if you use one, on your custom domain. Lovable's docs say the Site URL and Redirect URLs are in Auth settings under Advanced.
Try a signed-in user from a second account and confirm user A cannot see user B's records. Review the row-level security policies (More, Cloud, Database, RLS policies).
Save, edit and delete one record and reload the page to prove the data persists.
Open a private page while signed out and check you are turned away, not shown the content.
Check forms with empty, very long and unusual input; look at error messages and what is stored.
Check the custom domain: padlock present, the bare domain and the www version both reach the app, no old site appears.
Check text and links: placeholder copy, dead links, missing legal pages, contact address.
Run Lovable's Quick scan from the Publish dialog and read the findings.
Re-test after every fix, on the published address again.

What an independent test adds

Lovable's testing is run from inside the project, by the same environment that wrote the app. An independent test is different in three ways, and it complements the above rather than replacing it.

It sees the published app like a visitor. It starts from the address you share, not from your project, so it catches what only shows live: a blank page, a broken redirect, a page that needs a login you forgot.
It does not see your code. It cannot be tempted to excuse a behaviour because the code looks right. It judges the result.
It is repeatable. The same read-only test can run again after each change and compare itself with the previous run, which is how regressions are caught.

An independent test is a second pair of eyes, not a substitute for your own judgement, and a clean report shows what was seen, not that the app has no defects.

Test your Lovable app with Avalyz

Avalyz tests a web app from the outside, in real browsers, and returns a GO, NO-GO or INCONCLUSIVE verdict with evidence.

Free test, no sign-up: paste your published address on the free test page, 3 tests a day. Or open https://avalyz.com/essai?url=YOUR_APP_URL with your address in place of the placeholder.
Read-only by default: nothing is created or changed on your app.
Optional test account: give a test login and Avalyz signs in, then explores the signed-in pages; sign-in is the sole form it submits.
Report you can paste back: a plain-language summary and findings ranked by severity with annotated screenshots, which you can paste into Lovable's chat as a to-do list. A PDF sign-off report and a comparison with the previous run come with it.
Plans: see pricing; there is also a 14-day trial with no card.

The badge on the integrations page turns your README into a one-click test link.

FAQ

Does Lovable already test my app?

Yes: browser testing, frontend tests and backend verification exist, plus a security scan when you publish. They run when requested and from within the project. An outside test of the published address is a complement.

Should I test the preview or the published app?

The published app. The preview is your work in progress and can differ from the live snapshot.

Can a test break my Lovable app or fill it with fake data?

A read-only test does not create or change content. Write mode exists only at your request and with proof or attestation that you may test the site.

Often the new address is missing from the redirect URLs. See Lovable app not working after publishing.

Is this the same for other builders?

The method is. See Bolt, Replit and the general vibe-coded app guide.