What order should I test things in?

Happy path first to confirm the deploy didn't break anything, then errors and empty states, then auth and payments if applicable, then environment variables and secrets. Fixing config issues after you've already found broken flows can undo your testing, so security and config are worth a final pass at the end too.

Do I need to test on a real phone?

A resized browser window catches most layout issues, but testing on an actual phone at least once catches things like touch target size and mobile keyboard behavior that a resized window misses.

Can a scan replace this manual testing?

No. A scan reviews risky patterns in your repository and configuration — secrets, environment variables, deployment gaps. It does not click through your signup form or complete a test payment. Both are useful, and they check different things.

How much testing is "enough" before a first launch?

Enough to be confident your core flow works, your errors don't crash the app, and nothing sensitive is exposed. Perfect coverage isn't the bar for a first launch — a safe, working core experience is.

What if I find a bug during testing?

Fix critical and security-related bugs before launch. Minor cosmetic issues can often wait for a fast follow-up after you've launched to a small audience.

Guides

How to Test a Vibe Coded App Before Launch

You vibe coded your way to a working app — prompt, preview, adjust, repeat — and now it is time to actually test it before anyone else sees it. This guide gives you a specific order to test in: the happy path first, then errors and empty states, then auth and payments if you have them, then the configuration details that only matter once the app leaves your laptop. Work through it top to bottom before you share the link.

Updated August 2026 · 9 min read

Written for AI makers using tools like Cursor, Bolt, Lovable, Replit, Claude, and ChatGPT.

Quick answer

Test a vibe coded app in this order: the happy path (your core feature works start to finish), errors and empty states (bad input, no data, failed requests), auth and payments if your app has them, environment variables and API URLs (production values, not localhost), and secrets and debug settings (nothing exposed, debug mode off). Finish with a launch readiness scan of your GitHub repo to catch anything the manual pass might have missed in your config.

Who this is for

You vibe coded an app with an AI coding tool and have not tested it beyond the happy path
You want a specific test order instead of randomly clicking around
You are about to share the live URL and want a structured last check

What you'll need

A deployed URL for your app (testing localhost only will miss production-only issues)
Test data you're comfortable creating and deleting — a throwaway account, a test payment card in sandbox mode
About twenty to thirty minutes for the manual pass, plus a few minutes for a repo scan

Test the happy path

Start with the path you already know works — the exact sequence you used while vibe coding the app. This confirms nothing broke between your last prompt and the deployed version, and it gives you a baseline before you start trying to break things.

Do this on the actual live URL, not localhost, and in an incognito window so no cached session or local storage quietly helps you along.

Load the homepage fresh and confirm it renders correctly with no console errors
Complete the single core action your app exists for, start to finish
Confirm the result is what you expect — data saved, page updated, confirmation shown
Reload the page after completing the action and confirm the result persisted

Test errors and empty states

Vibe coding sessions almost always test the case where everything goes right, because that is the case you were building toward. Real users generate the other cases constantly, usually by accident.

Submit a form with missing required fields and confirm you see a clear message, not a silent failure
Enter an obviously invalid value (bad email format, negative number where it doesn't make sense) and check the response
Load a page or view that has no data yet — a new account's dashboard, an empty list — and confirm it shows something reasonable instead of a blank or broken screen
Turn off your wifi briefly mid-action, if you can, to see how the app handles a failed network request
Trigger a 404 by visiting a URL that doesn't exist and confirm it shows a real page, not a raw error

Test auth and payments if applicable

If your app has accounts or takes payments, these flows deserve extra attention, since a mistake here directly affects user trust or your revenue. Test them in a sandbox or test mode wherever your payment provider offers one.

Sign up with a new account, log out, and log back in with the same credentials
Try to sign up with an email or username that already exists and confirm you get a clear error, not a silent duplicate
Test password reset end to end if the feature exists
Run a test transaction using your payment provider's sandbox mode and confirm the app records it correctly
Confirm a canceled or failed payment is handled gracefully, not just the successful path
Check that logging out actually clears the session, by trying to access an authenticated page afterward

Check environment variables and API URLs

This is where a lot of vibe coded apps quietly fail after deploy: the frontend keeps calling a localhost API address because nothing told it to use the production URL instead. Confirm this explicitly rather than assuming it updated itself.

Open your browser's network tab while using the live app and confirm API calls go to your production backend, not localhost
Confirm every environment variable listed in .env.example is also set, with production values, on your hosting dashboard
Double-check variable names match exactly between your code and your host's dashboard
If your frontend and backend are on different domains, confirm CORS is configured to allow your production frontend

Check secrets and debug settings

Before you finish, confirm nothing sensitive is exposed and that production doesn't show internal debugging details to visitors.

Search your repository for API keys, passwords, or tokens that may have been hardcoded during a quick prompt-and-fix cycle
Confirm .env is listed in .gitignore and was never committed
Confirm debug mode is off in production — trigger an error on purpose and check that you see a friendly message, not a stack trace with file paths
Check that any admin or internal routes require authentication before they're reachable

Scan launch readiness

Manual testing is strong at catching broken flows but weak at catching things that only show up by reading code and config carefully — a scan is a fast way to review those risky patterns as a final pass, on top of everything you just tested by hand.

Connect your GitHub repository to a launch readiness scan, review anything flagged as critical or high severity, and fix those before sharing the link broadly. This step is meant to help you launch with more confidence, not to replace the manual testing you already did above.

Common mistakes

Only ever testing the happy path
What happens: The first real user submits a blank form or hits an empty state and sees a broken page.
How to fix it: Deliberately test bad input and empty states before launch, not just the flow you built the app around.
Testing on localhost and assuming production behaves the same
How to fix it: Always do a final test pass on the actual deployed URL, since environment variables and URLs often differ.
Skipping payment testing because "it's just a demo for now"
How to fix it: Run at least one test transaction in sandbox mode — payment bugs are expensive to discover from a real customer.
Forgetting to check what a logged-out or brand-new user sees
How to fix it: Test in an incognito window so you experience the app the way a first-time visitor actually does.
Relying only on a scan and skipping manual testing entirely
How to fix it: Use a scan to check common launch blockers in code and config, then still test your flows by hand — the two catch different problems.

Copy-ready prompt

Copy-ready testing prompt for your AI coding tool

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready to paste

Help me put together a manual test plan for this app before I launch it. Base it on the actual routes, forms, and features you can find in this codebase.

Include test cases for:
1) The core happy path for the main feature
2) Form validation and error states (missing fields, invalid input)
3) Empty states (new account, no data yet)
4) Auth flows if the app has accounts (signup, login, logout, password reset)
5) Payment flows if the app charges money, using sandbox/test mode
6) What should happen on a 404 or a failed network request

Then separately, review the code and config only (not runtime behavior) for: committed secrets, debug settings left on for production, missing .env.example entries, and hardcoded localhost URLs. Keep the two lists clearly separate since one requires me to click through the app and the other you can check directly.