How to test a vibe-coded app: the 6-step process

In a June 2026 audit of 49 Show HN launches, 38 (78%) shipped with at least one critical verified finding on day one. To test a vibe-coded app before you let users in, run this 6-step process — ordered by what that audit shows actually breaks, not by intuition:

1. Map your 3-5 critical paths — signup, the core action, payment, data access.
2. Define what “working” means for each one before you test it.
3. Run the automated pass first — and know exactly what it can’t do.
4. Do the manual pass for the steps a tool can’t reach.
5. Stress the edges and test on a real device, not an emulator.
6. Re-test after every AI change — the velocity is the whole problem.

This is the process article — the ordered routine. It is not the catalog of failure modes (that’s the catalog of vibe-coding failure modes, ranked by how often they break), not the tickable list (that’s the runnable 10-item vibe-coding testing checklist), and not the yes/no verdict (that’s the page that helps you score whether your vibe-coded app is production-ready). It links to all three and duplicates none. What it adds: the steps are sequenced by our own audit frequencies, the trust question gets a real answer, and the line between what a tool can and can’t do is drawn honestly.

How to test a vibe-coded app: the 6-step process

Most “how to test a vibe-coded app” articles give you the same six-ish steps in roughly the same order: map paths, walk manually, automate, prioritize payments, watch for silent failures, re-test. The spine is right. What every page-1 result hand-waves is the order (they guess), how an AI tester decides pass or fail (they don’t say), and which steps a tool provably can’t do for you (they imply it does everything).

We can fix all three because we have the data and we built the tool. The ordering below comes from our June 2026 audit of 49 Show HN launches — the only first-party dataset in this category. The trust answer comes from how the product actually decides a finding is real. And the automation boundary comes from our own product’s limits, stated plainly.

Step 1 — Map your 3-5 critical paths (ordered by what breaks most)

Write down the 3-5 paths a user must complete for your app to mean anything: usually signup → core action → payment → data access. Don’t test everything; test the paths whose failure is fatal.

Order them by what actually breaks. In the 49-launch audit, the most frequent verified findings on the public pages were, in order: no analytics events at all (38 of 49 sites), plus 3 more whose tag container loaded but fired nothing; no canonical link (24 sites); cookies set without the Secure flag (22); broken internal links (14); and JavaScript console errors on page load (10) (landing/src/content/blog/we-audited-49-show-hn-launches.md). That’s a frequency observation, not a severity ranking — “no canonical link” is common but rarely fatal, while a broken payment webhook is rare in a public-pages audit only because that audit can’t reach it. Use the frequencies to decide what to check first, then apply your own judgment about what’s worst for your app.

The highest-stakes path is almost always signup, because everything else depends on it. If you do nothing else, test your signup flow before launch — a session that looks logged-in but never persisted is the single most expensive thing to discover from a user.

Step 2 — Define what “working” means before you test it

Before you touch the app, write the success assertion for each path — the concrete, checkable fact that proves the step worked. Not “signup works” but: after submit, the success page renders and an auth cookie is set with the Secure flag and an incognito window can reach an authenticated route.

This matters more for vibe-coded apps than for hand-written ones. The classic AI-generated failure is the optimistic then() chain: the client catches the 200, flips the UI to “Success!”, and the server-side write that was supposed to happen in a separate code path silently didn’t. The UI lies. If your only assertion is “the success page showed up,” you’ll pass a broken app. The assertion has to name a fact the server controls — a row written, a cookie set, an email sent — not just a screen the client rendered.

Writing the assertion first is also what makes the next step possible. A test is only as good as its pass/fail condition, and a vague one (“looks fine”) is how silent failures survive.

Step 3 — Run the automated pass first (and know what it can’t do)

Run an automated audit on your entry URL before you start clicking. A good one opens a real browser, captures the actual network traffic, walks your public pages, and reports verified findings in about a minute. Prufa’s free audit does exactly this; it runs the deterministic checks under backend/service/checks/ — tracking, security, SEO, forms, consent, mobile, performance, accessibility, and link-graph analysis — over the pages it can reach.

The point of going first is leverage: the static and flow checks catch the high-frequency findings from Step 1 (the non-firing analytics, the insecure cookies, the dead links, the console errors) faster and more reliably than you will by eye. Let the machine clear the table of the mechanical stuff so your manual time goes to the things only a human can judge.

Now the honest part nobody else states. An automated audit provably cannot:

• Pass a reCAPTCHA or bot wall. When a run hits one, the report should say so rather than guess. In our pipeline that’s a real run state (RunStatus.BLOCKED) — the report doesn’t render a fake all-clear; it tells you it was blocked.
• Complete OAuth without a real Google account. “Sign in with Google” needs an actual identity the tool doesn’t have. The walk stops at the provider’s screen.
• Confirm an email actually arrived. A tool can submit your signup form; it can’t read your user’s inbox or your DNS records. “Did the welcome email land, and not in spam?” is human-only.

Any audit that claims it did these things is lying to you. The boundary is the trust signal: a tool you can trust tells you where it stopped. The rest is Step 4.

Step 4 — Do the manual pass for what the tool can’t reach

Open a clean, incognito browser (or one you don’t normally use) so cached auth doesn’t mask a broken login, and walk each critical path yourself — checking the exact assertions you wrote in Step 2. These are the steps the automated pass handed back to you:

• The email actually arrived. Sign up with a fresh address, then read the inbox. In spam → fix your DNS records (SPF/DKIM). Missing entirely → your send code never ran. The form said “check your email”; the email is the proof.
• The OAuth round-trip completes. Click “Sign in with Google,” go all the way through, and confirm you land authenticated — not on an error page, not back at the login screen.
• Payment confirms end-to-end. Run a test-mode checkout, then check that the server updated: the subscription row exists, the entitlement flipped. The Stripe dashboard showing a 200 is not the same as your database having the row — the webhook returning 200 OK without writing the row is one of the most-reported vibe-coding failures (research/2026-06-12-community-listening-vibe-coding.md).
• The session persists. After signup, refresh in a fresh incognito window and hit an authenticated route. A 401 means the cookie or session row never wrote — exactly the Step 2 lie.

While you’re in here, do the one check the audit can’t do for you because it’s not about a flow at all: View Source and search the shipped JS for secret prefixes — sk_live_, AKIA, sk-, ghp_, xoxb-. The most expensive failure founders report in this category is a server key leaked into the client bundle; a vibe-coded startup publicly reported a $2,500 loss to API keys exposed in client code (research/2026-06-12-community-listening-vibe-coding.md). If you find a match, rotate the key immediately — the pre-rotation key is already in Google’s index.

Step 5 — Stress the edges and test on a real device

The happy path is the path you built and the path the LLM tested. Spend ten minutes deliberately breaking it:

• Empty and malformed inputs — submit the form blank, paste a 5,000-character string, use a capitalized email, enter an emoji where a number goes.
• Rapid double-clicks on submit — does it create two records?
• Back-button mid-flow — hit back during checkout, then forward. Does the state survive, or do you get a charged card and no order?
• A real phone, not desktop emulation. Device emulation in DevTools approximates the viewport, not the actual touch targets, the real network, or mobile Safari’s quirks. Borrow a phone and tap through your critical path on it.

This pass is table stakes — every credible launch guide says do it, and they’re right. Keep it tight; the differentiated value of this article is the ordering, the trust answer, and the boundary, not a long edge-case list.

Can you trust an AI to test the app it just built?

This is the question under all the others, and the SERP dodges it. Competitors say “the AI reads your code and tests it” and stop — leaving you to trust a black box built by the same kind of system that wrote the bug. The honest answer hinges on one distinction: who decides pass or fail.

The architecture we built Prufa on, and the one we’d recommend to anyone evaluating an AI tester, is: the LLM navigates, plain code verifies. The model is good at the fuzzy human part — reading a page, finding the “Sign up” button, deciding what looks like a checkout flow. It is not the thing that grades the result. After the model claims it found a signup flow, plain deterministic code re-checks the entry element in the actual DOM before that claim counts (FlowDetection.verified_in_dom in backend/service/checks/schema.py); the documentation calls this out as advisory by definition — “the agent looked, it did not walk.” For the full mechanics, see how plain code re-verifies what the LLM navigated.

That split shows up as two tiers in every report. A verified finding is a machine-checked fact: the network capture saw zero analytics beacons, the cookie has no Secure flag, the link returned 404. An advisory finding is the model’s opinion — a UX read, a “this copy is confusing” — and it is never phrased as broken (FindingTier in schema.py; the rule in docs/PLAN.md: “the LLM navigates, plain code verifies; LLM-judged UX findings are advisory-tier only”). There’s even a guard against the model’s own failure masking a fact: “no analytics fired” is only emitted when capture provably worked — CDP attached and real network traffic observed (CaptureMeta.capture_trustworthy) — so a broken run can’t report a clean app as broken.

So: can an AI test the app it just built? Yes — if the grading is deterministic and external to the model. If the same model both drives the test and decides whether it passed, you’ve asked the thing with the blind spot to confirm its own work. When you evaluate any AI QA tool, ask exactly one question: when it says “this works,” who checked — the model, or plain code?

Step 6 — Re-test after every AI change

Vibe coding’s defining feature is velocity: you ship a change, the LLM touches three files you didn’t read, and the thing that worked an hour ago is now subtly broken. A one-time test before launch is necessary and insufficient. The process only holds if it re-runs — re-running on every change is what turns these six steps into the vibe-coders’ QA workflow rather than a launch-day ritual.

Two things make that practical without re-doing the half hour every time. First, the automated pass from Step 3 is the part you can cheaply repeat — re-run the audit on every deploy and diff it against the last run, so you’re alerted on change, not on the existence of findings you already accepted. (Prufa’s monitoring tier does this on a schedule; the audit’s delta engine keys on a stable finding_key so it reports what’s new, per schema.py.) Second, because there’s an agent surface — a CLI and an MCP server — the same agent that made the change can call the re-verification itself, instead of waiting for a human to remember: you can run the 6-step process from Cline (or any MCP-capable agent), so the tool that wrote the code also checks it.

What you still can’t automate away is the first ~30 minutes after a deploy: watch your error logs and re-walk the one or two paths the change actually touched. When you’re ready to turn “did this break anything” into a repeatable verdict rather than a vibe, the page that helps you score whether your vibe-coded app is production-ready is the next stop.

How long should testing a vibe-coded app take?

A realistic first pass is about half an hour: roughly 60 seconds for the automated audit to walk your public paths and surface the verified findings, plus 20-30 minutes for the manual pass that covers what the tool can’t reach — the email round-trip, the OAuth hop, payment confirmation, the secret-prefix grep, and a real-device walk.

After launch, the math changes: the automated 60 seconds re-runs on every deploy (cheap, repeatable), and you only re-do the manual portion when a critical path actually changes. The trap is treating the pre-launch half hour as a one-time event. The thing that breaks a vibe-coded app in week two is the change you shipped in week two — which is why Step 6 exists.

FAQ

Can you trust an AI to test the app it just built?

Only if the grading is deterministic and external to the model. The honest way to run an AI tester is to split the work: the LLM navigates the app (finds the signup button) but plain code decides pass or fail by inspecting the DOM, cookies, and network traffic. If the same model both drives and grades, you have asked the thing with the blind spot to confirm its own work. Prufa enforces this split — LLM-judged UX findings stay advisory-tier.

How do you test a vibe-coded app without coding?

Run a free automated audit on your entry URL: it opens a real browser, walks the public paths, and reports verified findings in about a minute, no code required. The manual fallbacks (sign up with a fresh email, check the inbox, open an incognito window) also need no code. But some steps a tool provably cannot do for you — pass a reCAPTCHA, complete OAuth without a real Google account, or confirm an email actually arrived. Those stay human.

How long does it take to test a vibe-coded app?

A realistic first pass is about half an hour: roughly 60 seconds for the automated audit to walk your public paths and surface the verified static and flow findings, plus 20-30 minutes for the manual pass that covers what the tool can’t reach — the email round-trip, the OAuth hop, payment confirmation, and a real-device check. The automated part you can re-run on every deploy; the manual part you do once and repeat when a critical path changes.

What should I test first in a vibe-coded app?

Test your critical paths first, ordered by what actually breaks. In a June 2026 audit of 49 Show HN launches, the most common verified findings were no analytics events at all (38 of 49 sites), no canonical link (24), cookies without the Secure flag (22), broken internal links (14), and JavaScript console errors on load (10). Signup, payment, and core-action flows come next — rarer in the data only because a public-pages audit can’t always walk them.