Decide what "works" means
A preview loading is not a journey. Neither is "the homepage looks right." Write down the thing a stranger is supposed to be able to finish, in the words you'd text a friend.
Three is enough for a first ship. Examples that hold up: a new visitor creates an account and lands in an empty workspace; a signed-in user pays and sees a receipt; a second user cannot open the first user's records. If you cannot name the journey, you cannot know whether it broke.
Write the expected result next to the steps. "Pay button does something" is not an expected result. "I see order #… and the charge appears once" is.
Run it as a user, not as the writer
Open a private window. Use an email that is not yours. Do it on a phone. The editor you used to generate the app is the worst possible place to decide that it works, because you already know which buttons you meant to click.
Do not paste a screenshot of what's broken back to the same AI and accept "fixed" as the final word. Replit's Agent 3 is the most thorough AI-side tester of the bunch, but it still grades its own test and fixes what it finds. That is genuinely useful work. It just is not an outside check. Cited on the who checks page.
If you already keep Playwright or Cypress, keep them. This page does not replace a team’s suite. It is for the person who just built an app with an agent and needs to know whether a human can finish the job.
Do not trust these three "it works" signals
Three things get mistaken for proof.
A page that opens. Lovable's editor link opens right up and looks fine, but it is an empty shell that still needs sign-in behind it. The page opening is not the same as the product being there. Lovable hosting docs describe published apps; the editor trap is a first-hand pattern we recorded ourselves, not a Lovable marketing claim.
The technical detailLovable's editor URL returns HTTP 200 for a client-side shell that still requires sign-in.
A green checkmark. Lovable shows a banner and a "Try to fix" button after a failed build, and v0 has an auto-fix step for common code errors. Neither of those is the same as someone actually clicking through the app. Lovable docs, Vercel on v0.
The AI's own test summary. Replit will reply with a summary of what it tested, plus video recordings, then fix whatever it found. Agent 3 launch. A summary written by the same AI that built the app is still that AI talking about itself.
Know whether there is anything public to test yet
If your preview only runs inside your own browser tab (this is how Bolt's editor preview works), nothing outside that tab can reach it, no matter what link you copy. Publish it, or test a copy of the code you have exported.
The technical detailOfficial WebContainers documentation says the runtime executes "entirely inside your browser tab." Bolt's in-editor preview uses that architecture.
If it is a v0 preview link, it usually asks anyone who opens it to sign in first, so you do not have anything public yet unless you have specifically shared a bypass link. A Replit workspace link can also change or stop working once you close the project.
The technical detailVercel preview deploys commonly return 401 Unauthorized unless you supply a bypass secret or a shareable link.
The honest path for most people is: get the actual code (export it, download a zip, or use a folder you already have) and run it somewhere you control. Pasting the preview link into a checker just rings a doorbell. It does not scan anything.
Stop when you hit a sign-in screen
Any checker that claims to get past a sign-in screen without a test account you gave it is either lying or trying to break in. Note that you reached the login page. Everything behind it stays Unknown.
If you want proof of what happens after sign-in, make a separate test account with no real customers and no real secrets attached to it, and only use it for checks. Even Hercules, one of the more thorough tools, documents that its automated tests cannot cover anything behind login. That is a real limit, not a knock against them.
A robot-check is a different kind of stop. If something like Cloudflare or a "prove you're human" challenge blocks you, the honest word is Blocked. That does not mean checkout is broken. It means you never actually reached checkout.
Re-check after every prompt
The sentence “I only changed the colour” is how regressions arrive. The colour lives on the same surface as the pay button, the same layout as the empty state, the same CSS as the disabled submit.
After any change, redo the checks that touch that same part of the app. You do not need any special tool for this, just a short list and the discipline to open a private window again. The same rule applies when you update a library or package: re-run what was already proven to work. That is the entire idea behind did my upgrade break my app.
If a check cannot possibly fail, it is worthless. Throw it away. A journey that always "passes" because nobody defined what success looks like is not really a check at all.