Skip to content
FlowPatrol
Free scanLog in

Guide

How to test a Lovable app before launch

A Lovable app can look finished in the editor and still fail the first real signup. The preview is often already signed in, and an AI edit can rename a button, drop a label, or ship without the live environment values while the homepage still loads. Run this pass on the published URL before you share it, and again after any prompt that touches signup, login, or checkout.

Test the published URL, not the preview

  1. Publish, then copy the public URL. Clicking only inside the Lovable editor hides a missing environment variable and a session that is already logged in.
  2. Open that URL in a private window so you are not already signed in.
  3. If the app charges money, switch the payment provider to test mode and use its test card.
  4. Reserve one email address you have never used in this project.
  5. If the page talks to Supabase or another auth service, confirm the published deployment has the project URL and public key that client expects. The page can load while every auth request fails.
  6. Test only an app you are allowed to test. The terms cover the free scan too.

Walk signup from a brand-new visitor

Write down the words you see. After the next AI edit, those notes are what you compare against the live screen.

  1. On the public homepage, find the control that starts account creation. Record the exact words, such as “Sign up” or “Get started”.
  2. Open the form. Record each field’s label or placeholder, and any password rule the form states.
  3. Submit the fresh email and a password that meets those rules.
  4. Finish the next step the app asks for. If it sends a confirmation email or a one-time code, open that message and complete it. A page-load check cannot read an inbox.
  5. Confirm you reached the screen a new user should see. Record the URL path and the sentence that shows only after signup.
  6. Reload. A blank shell, or a bounce back to the form, means the session did not stick.
  7. Submit the same email again. The app should say the address is taken. A spinner that never ends, or a stack trace, is a failed launch.

Log out, log in, and log in again

  1. Log out of the new account. If you cannot find logout, record where you expected it. Missing logout is part of the result.
  2. Log in with the same email and password. You should reach the same kind of screen you saw after signup.
  3. Submit the wrong password once. You want a visible error. A button that stays busy with no message is a failure.
  4. Log out and log in a second time. The second login is where a bad redirect or a half-saved session usually shows up.
  5. If the product offers password reset, request one reset and finish it when the email arrives. Record the button text on that form.
  6. Still in the private window, while logged out, open the dashboard path directly. You should see a login wall. An empty layout with no redirect means the guard painted the shell and the data call failed.

If you charge money, finish one test payment

Skip this section when the app does not charge yet. Do not invent a payment step so the list looks complete.

  1. Continue as the test user you just created.
  2. Choose the cheapest plan or product you actually intend to sell.
  3. Reach the payment step on your own site. Record the button text, such as “Pay”, “Subscribe”, or “Checkout”, and the URL.
  4. Complete one payment in test mode. Stop when your app shows the state you will treat as paid: a sentence, a receipt page, or an unlocked feature.
  5. A pricing page that loads is not a passed checkout. The paid state is the pass.
  6. Reload the account or success page. The paid state should still be there.

Stripe Checkout, PayPal, and similar hosted payment pages live on another hostname. Complete one of those yourself in test mode before launch. A later automated check that stays on your host can tell you the button and the success text on your pages are still present. It will not type a card number on the provider’s site.

Checks around the happy path

  • Narrow the window to a phone width and repeat signup. A control in the desktop header sometimes disappears when the nav collapses.
  • Open every header and footer link once.
  • Watch the browser console during signup and checkout. An auth client that failed to start leaves the form on screen and still blocks the account.

What to recheck after the next AI edit

A later Lovable prompt rewrites components while the homepage still returns a normal response. Compare the live app with your notes:

  • Signup, login, logout, and pay controls still use the words you recorded. A visitor can cope when “Sign up” becomes “Continue”. A later check that looks for the old visible text fails until you update the description.
  • Labels and placeholders still match. Filling a form uses the accessible label, the placeholder, or the textbox name. An unlabeled box breaks the visitor and the check.
  • The URL after login still contains the path you recorded, and the success sentence is still on the page.
  • If the edit touched auth or payments, recheck environment values on the published deployment. The preview can keep working after the public site lost them.

Walk the three flows again after any edit that touches them, and once more after the next unrelated prompt. The break often shows up in the edit after the one you meant to test.

What the free scan adds, and where it stops

The free scan takes the published URL and an email for the report. It does not create a FlowPatrol account or start a subscription. It opens the page and reports the HTTP status (missing, or 400 and above, is a failure), whether the final page is HTTPS, load time (a warning above 4 seconds), console errors as warnings, images that finished with no pixels, up to 12 http(s) links that error, failed network responses as warnings, and a screenshot.

The scan stops before Sign up, Log in, and Pay. It does not create a user in your app, read email, solve a captcha, or complete a card form. Use it beside this checklist. A watch that repeats the flows starts when you create an account.

Keep the same three flows running after launch

How it works: describe a flow in a sentence, such as “Sign up with a new email, then open the dashboard.” The stored plan opens a same-host URL, clicks visible text, fills a field by its label, placeholder, or textbox name, and checks for a sentence or a URL path. Plans stay at or under 12 steps. Test emails end in @example.com, so an app that rejects that domain fails the check even when a real visitor can sign up. Prefer a staging URL. Signup and checkout create real records, which the FAQ states. With no AI key, the plan only loads the URL. Regenerate it after a key is added.

On the pricing section the free scan is $0, Starter is $19/mo (1 app, 3 flows, every 24 hours), and Pro is $49/mo (3 apps, 10 flows, every 6 hours where cron allows it, daily on Vercel Hobby). Paid plans include Run now, a deploy webhook, and an email that names the failed step, links a screenshot, and includes a paste-ready prompt. Pro adds a weekly summary. PayPal bills monthly. The refund policy covers cancellation. The check cannot finish email confirmation, a captcha, or a passkey. Console noise alone does not fail a watched flow, and a pass is not a promise that every customer path works.

Before you share the URL, you should have a private-window signup that survives reload, a second login, a login wall on protected pages, one test payment if you charge, working header and footer links at phone width, and notes for the button text and success sentence. To rerun those flows after later edits, describe them from signup. How that compares with testing by hand is on the facts page. FlowPatrol is built for this workflow. It is not an affiliation with Lovable.