WT

Well Tested Team

Release confidence editorial

Vibe Testing

How to test a vibe-coded app before launch

A practical launch QA flow for apps built with Cursor, Lovable, Bolt, v0, Replit, or Claude Code: pick the public paths, run browser proof, and share evidence before traffic arrives.

Article

AI coding tools make launch velocity feel cheap. The risk is that the launch page, signup flow, onboarding screen, pricing page, or contact form quietly broke while the product still looks good in screenshots.

Before launch, test the paths that determine whether a visitor trusts you.

The five launch paths

Start with public, non-destructive pages:

  1. homepage loads and the main CTA is clickable
  2. pricing renders the right tiers and CTAs
  3. signup or waitlist accepts test data
  4. contact or demo request returns a success state
  5. docs, FAQ, or help links do not dead-end

Do not start with private dashboards, billing payment submission, or destructive admin flows unless you have explicit permission and a safe test environment.

Turn each path into a one-sentence goal

Useful goals are concrete:

  • "Open the homepage, click Pricing, and confirm the pricing cards render."
  • "Submit the waitlist form with test data and confirm the success message."
  • "Click each top navigation link and capture screenshot evidence after each page change."

Weak goals are vague:

  • "Check the site."
  • "Make sure everything works."
  • "Look around."

The browser can only prove what the goal names.

Capture proof, not vibes

A good launch test creates an artifact:

  • the target URL
  • the goal
  • every browser step
  • screenshots after movement
  • an honest pass, fail, partial, or unavailable state
  • a share link for the founder, PM, or QA reviewer

That artifact matters because launch decisions are social. Someone needs to see what was tested without opening logs.

Use proof pages as your launch checklist

For a small launch, run one proof page per critical path. For a larger launch, save approved scenarios and rerun them before posting the launch.

The minimum bar is not "all possible bugs are gone." The minimum bar is "the paths we are asking customers to use have visible evidence."

What to do when a proof fails

Do not hide it. Failed proof pages are useful because they show exactly where the launch path broke.

Fix the issue, rerun the same goal, and keep the passing proof page attached to the launch checklist. If the browser could not run because the environment was unavailable, treat that as a launch blocker too.

The launch rule

If the page is important enough to promote, it is important enough to test with a real browser.

Vibe testing · live in private beta
Test a URL with the AI planner.
Paste a URL and one sentence — the AI planner drafts a Playwright scenario, the browser runs it, the vision pass scores it, and you get a shareable proof page.
Test a URL

Free gives you 3 runs per month to prove the loop; Starter and Growth have a 7-day trial (card on file, no charge if you cancel).

Related articles

Same category—different angles.