The QA Checklist to Run Before You Launch a Lovable or Bolt App

TL;DR: The pre-launch checklists you’ll find for Lovable and Bolt apps are mostly security and infrastructure audits: exposed keys, row-level security, backups. Those matter, but they don’t tell you whether a stranger can actually sign up and use the thing. This is the behavior half of the checklist, seven checks you run against the live URL you’re about to publish, plus how to keep running them after launch day.

You’re a day or two out from putting the app in front of real people. It works. You’ve clicked through it more times than you can count. And you have a low, specific dread that something you can’t name is going to break in front of the first ten users, because your app was written by an AI that has never once used it.

Why the checklists you found don’t cover this

Search “pre-launch checklist for a vibe-coded app” and you’ll get good, serious lists. They’ll tell you to check for API keys in your client bundle, to verify Supabase row-level security scopes properly, to confirm your Stripe webhook verifies its signature (Stripe’s own docs explain exactly why an unverified webhook lets anyone fake a payment), to set up error tracking and database backups.

Run those. They’re real, and the failure modes are ugly.

But notice what they have in common: every one of them is a check on your code or your infrastructure. You open a file, read a config, search a bundle. None of them answer the question a launch actually turns on, which is whether a person who has never seen your app can get from your homepage to the thing they came for without hitting a wall.

That’s a different kind of check, and it’s the one that’s hardest to do honestly, because you are the worst possible tester of your own app. You know which button to press. You know the flow works if you do it in the right order. You’ve never once used the app the way a confused stranger will.

The seven checks

Each of these runs against your deployed URL, not your preview environment, not localhost. Do them in a browser you’ve never logged into the app from.

1. The signed-out first visit. Open your live URL in a fresh incognito window. Don’t touch anything for ten seconds. Does the page render fully, or does something flash, shift, or sit on a spinner? Then try to do the main thing your app does. If the app needs an account, can you find the way to make one without hunting?

2. Signup with an email you’ve never used. Not your test account. A genuinely new address. Go all the way through: submit the form, wait for the verification email, click the link, land wherever it drops you. Two things break here constantly in AI-built apps. The verification email lands in spam or never sends at all because the email provider was configured for the preview domain. And the post-verification redirect points somewhere that existed three prompts ago.

3. The empty state. You’ve been testing with an account full of data. A new user has nothing. Log in as the account you just created and look at every main screen. An empty dashboard that renders a blank white box, or worse, crashes on a .map() over an empty array, is the single most common thing founders never see because their own account has always had data in it.

4. The path you never demoed. Think about how you’ve always walked the app: homepage, signup, dashboard, create thing. Now do it backwards or sideways. Refresh mid-flow. Hit the browser back button after submitting a form. Open a deep link to an interior page directly rather than clicking to it. Submit a form twice. AI builders generate the happy path beautifully because the happy path is what you described in your prompt; everything adjacent to it was never specified, so it was never considered.

5. The failure path. Enter a bad email in the login form. Enter the right email with the wrong password. Upload a file that’s too big, if you accept uploads. What does the user see? “Something went wrong” with no next step is a bug. So is a form that silently does nothing on submit, which is the most common one, because the AI wired up the error state visually and never connected it to a real error.

6. Your phone. Not the responsive preview in DevTools. Your actual phone, on cellular, not wifi. Most first visits will be mobile, and AI-generated layouts routinely produce a desktop design that technically reflows but has a button under a fixed header or a modal you can’t scroll to the bottom of.

7. The domain switch. If you’re moving from a .lovable.app or .bolt.host URL to your own domain for launch, that switch invalidates half of what you just tested. OAuth callbacks, email links, CORS rules, and cookie domains are all pinned to the old host somewhere. Lovable’s publish docs are clear that you have to publish before a custom domain will serve your site, which means the first time your app runs on its real domain is often launch day itself. Re-run checks 1 through 5 on the new domain. All of them. This is not optional and it is the step everyone skips.

Doing this without spending your launch day clicking

Seven checks, done properly, is maybe an hour. That’s fine once. The problem is that it isn’t once. You’ll ship a fix on launch morning, and now the list is stale. You’ll ship three more that week.

This is where WayRunner fits, and I’ll be specific about the mechanism rather than vague about the benefit. You paste the URL you’re launching on and write each check as a sentence, the same sentence you’d say out loud: “sign up with a new email, confirm it, and check the dashboard loads with an empty state.” A Planner turns that into browser actions, and a real Chromium browser carries them out against your live app, screenshotting after every step.

One piece of this was built for exactly the situation in check 7. Before WayRunner spends a full run, it does a feasibility pass: a quick probe of the URL plus a sanity check on whether the instruction is even achievable on that page. We added it to avoid burning a run on an unreachable site, but the side effect turned out to be more useful than the original reason. Point it at your brand new custom domain on launch morning and a DNS record that hasn’t propagated, or a redirect loop from a half-configured SSL certificate, comes back in seconds as “this URL isn’t reachable” rather than as a confusing test failure ten steps deep.

When a step does fail mid-run, a separate Failure Analyst reads the full executor transcript and the screenshot and writes out what actually went wrong in plain language. That’s the part that matters if you’re not an engineer. “Step 6 failed” is useless. “The signup button was clicked but the page never navigated; the form shows a validation error under the email field” tells you where to point your next prompt.

Credentials work the way you’d want for a real login flow: they go into an encrypted vault and get injected into the browser at the moment of typing, so the model deciding what to click never sees your password.

After launch, this becomes a different problem

The checklist above is a launch-day artifact. What replaces it the day after is a short list of flows you re-run every time you change anything, which is a habit rather than a checklist. We wrote that process up separately in how to do regression testing without a QA engineer, and it’s worth reading before you ship your first post-launch fix, because the failure mode changes shape once you have users. A broken flow before launch costs you an afternoon. A broken flow after launch costs you the users who hit it and never came back to tell you.

If you want the step-by-step version of writing these as testable instructions, testing your Lovable, Bolt, or Replit app before you ship it walks through one real flow end to end.

The takeaway

Run the security checklists; they cover ground this one doesn’t. Then run these seven, in a clean browser, on the domain you’re actually launching on, as a stranger rather than as the person who built it. Most launch-day disasters aren’t exotic. They’re a verification email that never arrives and an empty dashboard that renders a blank page, both of which you’d have caught in twenty minutes if you’d looked at the app the way a new user does.

If you’d rather not do that by hand every time you ship: wayrunner.run/#signup.