How to Test a Lovable App Before Launch

To test a Lovable app before launch, run both of Lovable's security scans, then test what the scans cannot see: sign in as two users and try to read each other's data, walk sign-up and password reset on the published domain, call every server function without a session, run payments in test mode, and use the app on real phones. Budget two to four days.

If you would rather have your Lovable app tested for you, see how RAITHub would test this below.

Lovable is a fast way to get from an idea to a working product, and its built-in scans catch a real share of common mistakes. What it cannot do is use your app the way your users will: on an old phone, with a declined card, with two tabs open, or with a second account trying to see the first one's data. Everyone can build with AI now; almost no one has a tester. This guide is the tester's checklist, written for Lovable's actual stack.

What is different about testing a Lovable app?

The stack. Lovable's built-in backend, Lovable Cloud, is enabled by default and uses "Supabase's open-source foundation": a PostgreSQL database, authentication, storage and Edge Functions (Lovable Supabase integration docs). Projects can also connect their own Supabase project instead. Either way, the browser talks to the database through Supabase's API with a public key, so row-level security (RLS), the database rule that decides which rows each user may see, is what protects your data.

The front end depends on when the project was created. Lovable says that from 13 May 2026 new projects are server-rendered and built on TanStack Start, with server functions that let backend logic live next to the page; older projects were single-page apps built with React and Vite (Lovable blog, June 2026). That changes where you look for server code.

Project type	Where privileged code runs	What to call directly in testing
Created before 13 May 2026 (React and Vite)	Supabase Edge Functions; everything else runs in the browser	Each Edge Function, plus the Supabase REST API for every table
Created from 13 May 2026 (TanStack Start)	Server functions in the app, plus any Edge Functions	Each server function and Edge Function, plus the Supabase REST API
Either, with your own Supabase project	As above	As above, and check that the project you test is the one production uses

What do Lovable's security scans cover, and what is left?

Lovable runs two kinds of scan. According to its security documentation, the Quick scan runs on publish and reviews database access rules and RLS, password protection, known vulnerabilities in npm dependencies and authentication on exposed MCP servers. The Deep scan reviews application code for authorisation bypass, abusable endpoints, injection, leaked secrets, payment logic, authentication flaws and exposed data, but "does not run automatically as you work". Lovable's announcement of the newer scan flow says the basic scan "doesn't analyze your application code for logic flaws" (Lovable blog, June 2026).

Run both. Then accept Lovable's own caveat: the tools "do not replace a thorough security review". A scan knows patterns. It does not know that a coach should see their own clients but not another coach's, or that a refund must not be issued twice.

Area	Lovable scans help with	Still needs a test written for your app
Database access	Tables without RLS, policies that let everyone through	Policies that exist but are wrong for your roles
Secrets	Hardcoded keys (Deep scan)	Keys stored in tables an open policy exposes
Server code	Common unauthenticated endpoints (Deep scan)	A signed-in user acting on someone else's record
Payments	Obvious billing logic flaws (Deep scan)	Declines, retries, webhooks and double submits
Auth flows	Leaked-password protection settings	Email links and redirects on your real domain
Usability, phones, accessibility	Not covered	All of it

The reason this matters is on record. CVE-2025-48757 described Lovable projects with insufficient RLS policies; the researcher's statement reported 303 vulnerable endpoints across 170 of 1,645 projects analysed, about 10.3%, with emails, phone numbers, transaction records and API keys among the data exposed. The scans exist partly because of that. Testing is how you know your app is not in the next 10%.

What is the pre-launch test checklist for a Lovable app?

1. Run the Quick scan and the Deep scan, then fix and rerun

Treat every finding as a question, not an answer. If a fix changes a policy, retest the feature it protects: a tightened policy often breaks a screen that relied on the open one.

2. Test data access with two accounts

Create two ordinary users, A and B, and one per extra role. As A, create a record. As B, try to read, change and delete it, through the API rather than the UI, because the UI hiding a button proves nothing. A minimal test with supabase-js and Playwright's test runner:

import { test, expect } from '@playwright/test'
import { createClient } from '@supabase/supabase-js'

const url = process.env.SUPABASE_URL!
const publicKey = process.env.SUPABASE_PUBLISHABLE_KEY!

async function signedIn(email: string, password: string) {
  const client = createClient(url, publicKey)
  const { error } = await client.auth.signInWithPassword({ email, password })
  if (error) throw error
  return client
}

test('user B cannot read or change user A records', async () => {
  const a = await signedIn(process.env.USER_A_EMAIL!, process.env.USER_A_PASSWORD!)
  const b = await signedIn(process.env.USER_B_EMAIL!, process.env.USER_B_PASSWORD!)

  const { data: own } = await a.from('projects').select('id').limit(1)
  const targetId = own![0].id

  // RLS hides rows rather than erroring, so expect an empty result.
  const read = await b.from('projects').select('*').eq('id', targetId)
  expect(read.data).toEqual([])

  const write = await b.from('projects').update({ name: 'changed by B' }).eq('id', targetId).select()
  expect(write.data ?? []).toEqual([])
})

Replace projects with each table that holds user data, and add a third client that never signs in. Run it against a test project, never production. If a table has no RLS at all, the RLS-disabled fix has the SQL; this test is how you prove the fix holds.

3. Test auth on the published domain, not the preview

Sign up, confirm the email, sign out, reset the password and sign in again, all on the URL your users will use. Supabase expects the redirect URL in an auth link to match the project's Redirect URLs list, and uses the Site URL as the default when none is given (Supabase redirect URLs docs), so a flow that works in the Lovable preview can send users to the wrong place on a custom domain. Supabase auth that fails after deploy covers the usual causes.

4. Call every server function and Edge Function directly

For each one, send a request with no session, with user B's session acting on user A's data, and with oversized or malformed input. Expect 401, 403 or 400, never a 200 that did the work. If a function calls a paid API, check it has a per-user limit. Keys that ended up in the browser are a separate fix, covered in Lovable exposed API keys.

5. Run payments in test mode, including the failures

Use the card numbers in Stripe's testing docs for a success, a decline and a card that needs authentication. Check that the database changes only when the webhook confirms payment, that a double click does not charge twice, and that a refund removes access. Testing payments and webhooks has the full list.

6. Test with realistic data and a schema change

Load a few hundred records, not three. Long names, empty fields and many rows find layout and speed problems that a demo never shows. If you changed tables recently, check the change was applied the same way in production; Lovable and Supabase migrations explains why hand edits drift.

7. Use it on real phones and browsers

At minimum an iPhone with Safari, a mid-range Android phone with Chrome, and a desktop Firefox. Check forms with the on-screen keyboard open, sticky elements covering buttons, and file uploads from a phone camera. The cross-browser testing checklist lists what to cover.

8. Do an accessibility smoke check

Tab through sign-up and the main workflow with no mouse. Every control should be reachable, visibly focused and labelled. This is a smoke check, not an audit; the accessibility testing checklist covers WCAG 2.2 properly.

9. Retest after every prompt that touches a tested area

A prompt that restyles a page can also rewrite the query behind it. Keep the two-account test and a short smoke script, and rerun them before each publish. Regression testing after every deploy shows how to automate it.

How long does it take to test a Lovable app yourself?

For a small app with two roles, a payment flow and five to ten tables, plan on two to four days if you can read TypeScript and use the Supabase dashboard: half a day for the scans and fixes, a day for two-account and server-function tests, half a day for auth and payments, and a day for phones, browsers and the fixes that turn up. These are estimates for engineering guidance, not a quote.

The main risk of doing it yourself is that the builder grades its own work. Asking the AI that wrote a policy whether the policy is safe tends to get a confident yes. A second person, with a written list of what each role should and should not see, finds what the first one assumed. For a wider launch list, see making a vibe-coded app production-ready.

Buy, build or hire?

Route	Choose this when
A tool or SaaS testing platform (Lovable's scans, scanners, AI test generators)	You want a fast first pass on known patterns before every publish. Keep running Lovable's scans whatever else you choose.
Freelancers or crowdtesting	You need many devices and fresh eyes on the UI, and you can write the role map and judge the results yourself.
An in-house QA hire	You publish changes daily and have steady work for a full-time tester.
A managed QAaaS team	You want the checklist above done before launch, with a ranked report and tests left behind, without hiring.

Why RAITHub for this

• The same stack, built and tested. RAITHub builds on React, PostgreSQL and row-level security. Sundor Skin, a B2B platform RAITHub built, has 146 PostgreSQL tables with RLS and 530+ tests, including a suite that tries to read other buyers' data.
• Data access is tested first, because that is where Lovable apps have leaked in public.
• Honest about proof. RAITHub has no published case study of testing a Lovable app yet; the test counts above are from platforms RAITHub built.

When you don't need RAITHub

• The app is a prototype on test data with no real users. Run Lovable's scans and the two-account test above.
• You need a certified penetration test or a compliance attestation. RAITHub's security checks are application-level, against OWASP guidance, and produce no attestation.
• You want a tester placed in your team under your management. RAITHub does not offer staff augmentation.

How RAITHub would test this

• Role map: what each kind of user may see and do, agreed with you before testing starts.
• Data access and server code first: two-account tests against every exposed table, every Edge Function and server function, and a search of the bundle for secrets.
• Auth and payments on the real domain: sign-up, reset, sessions, Stripe test-mode successes, declines and webhooks.
• Phones, browsers and an exploratory pass: the main journeys on real iOS and Android devices, plus keyboard and accessibility smoke checks.

What you buy: a fixed-price launch audit, then an optional monthly QA plan if you keep prompting changes. You receive: a ranked bug report with reproduction steps and a suggested fix for each issue, any automated tests in your repository, and full IP under NDA. Fix the issues yourself with Lovable, or have RAITHub fix them under a separate fixed quote. See AI-built app testing and QA as a service. Next step: a free 15-minute call, then a written fixed quote.

Launching a Lovable app soon? Ask for a launch audit quote.

Frequently asked questions

Does Lovable test my app for me?

Lovable scans it. The Quick scan runs on publish and checks database rules, dependencies and MCP servers; the Deep scan reviews code for logic and access flaws when you run it. Neither uses your app as a real user would, so functional, device and payment testing is still yours.

Is passing Lovable's security scan enough to launch?

It is a good minimum, not a finish line. Lovable's documentation says the scans do not replace a thorough security review. Add two-account data tests and direct calls to your server code before real users arrive.

How do I test row-level security in a Lovable app?

Sign in as two different users through the Supabase client with the public key, have one create a record, and check the other gets an empty result when reading, updating or deleting it. Repeat for every table that holds user data and for a signed-out client.

Should I test in the Lovable preview or the published app?

Both, but sign off on the published app at its real domain. Auth redirects, environment settings and caching can differ, and your users only ever see the published version.

What should I test first on a small budget?

Data access between users, then sign-up and password reset on your domain, then payments in test mode. Those failures harm users and are expensive to fix after launch; layout issues can wait a week.

Can RAITHub fix the bugs it finds in a Lovable app?

Yes, under a separate fixed quote, or you can fix them yourself: each issue in the report comes with reproduction steps and a suggested fix you can give to Lovable as a prompt.