Vibe coding testing checklist: 10 things to verify before you ship

In a June 2026 audit of 49 fresh web launches, 38 (78%) shipped with at least one critical verified finding on day one. The vibe-coding-qa hub catalogs the nine failure modes that drove that number, ordered by how often they showed up. This article is the runnable version of that catalog: ten things to verify, each tied to a real Prufa check you can run in under five minutes.

The opposite of a 75-item generic list. Every item here is grounded in something measurable: a specific failure mode the 49-audit set caught, a specific check in backend/service/checks/ that catches it, a specific signal that shows up in the audit JSON, and a specific 5-minute manual fallback for the cases the audit can’t see (reCAPTCHA, OAuth without a Google account, email-actually-arrived).

For the broader pre-launch surface (sitemap, meta tags, broken links, console errors, the static-checker universal list), see Website QA checklist before launch, ordered by what actually breaks. The vibe-coding testing checklist is the vibe-coding-specific subset — the things the AI coding workflow is most likely to introduce.

The free 60-second audit on prufa.dev runs items 1-4, 6, and 8 automatically. Items 5, 7, 9, and 10 are the human-only ones.

The ten items, in priority order

1. No analytics events fire on a real browser load

The most striking finding in the 49-audit set: 38 of 49 sites had zero events firing on a real browser load. The script is in the HTML. The tag manager is configured. Nothing fires.

Why vibe coding causes it: the LLM generates the analytics tag and the consent banner as two separate features; they don’t get tested against each other. The tag fires only after consent = accepted; the audit (and the founder) tests before consent. In production, the same audit runs after a synthetic consent acceptance and sees nothing — because the tag manager isn’t reading the consent state, the event name doesn’t match the dashboard, or the dataLayer.push is being swallowed by an error handler.

The Prufa check: the tracking analyzer in backend/service/checks/tracking/. It watches the browser’s actual network traffic for the BeaconEvent v1 schema. If zero beacons fire and the capture was provably trustworthy, it’s a verified critical.

Signal in the result: a critical-tier finding with rule tracking.no_events. The signal is unambiguous — the capture_trustworthy invariant on CaptureMeta prevents the check from emitting “no analytics” when the audit itself was broken.

5-min manual fallback: open the site in a real browser, accept the consent banner, click around for 30 seconds, then filter the network tab by your analytics vendor’s hostname. If zero requests, you have this bug.

2. Cookies set without the Secure attribute

22 of the 49 audited sites had this. A session cookie is set over HTTPS but the cookie has no Secure flag. Some browsers send it on HTTP anyway; some don’t. Behavior is inconsistent across user agents — the bug that browsers “tolerate” until they don’t.

Why vibe coding causes it: the LLM writes document.cookie = "session=..." without thinking about flag discipline. The framework default isn’t Secure. The dev environment is HTTP, so the flag never matters locally.

The Prufa check: the cookies list on PageSnapshot is inspected by the consent and tracking analyzers. Both surface this as a warning.

Signal: a warning-tier finding with rule cookies.secure_missing.

5-min manual fallback: in DevTools → Application → Cookies, inspect any auth-related cookie. The Secure column should be checked.

3. No canonical link on the entry page

24 of 49 had this. The page renders fine, but <link rel="canonical"> is missing. Google picks a URL on its own — usually the one with the most inbound links, which may not be the one you want indexed.

Why vibe coding causes it: canonical links are SEO housekeeping, not user-visible behavior. The LLM is not optimized to add them.

The Prufa check: the seo analyzer in backend/service/checks/seo/.

Signal: an info-tier finding with rule meta.canonical_missing.

5-min manual fallback: view source on the homepage, search for rel="canonical". If missing, add it.

4. Broken internal links

14 of 49 had this. A link in the nav or footer 404s. Worse, an internal link in a CTA goes to a 404 and the founder doesn’t know until a user reports it.

Why vibe coding causes it: the LLM hallucinates routes that don’t exist, or copies a route from a different page and the IDs don’t match. The pages are generated as a set; the links between them aren’t validated as a graph.

The Prufa check: the link_statuses map on PageSnapshot is populated by the runner walking every <a href> on the visited pages; the ux analyzer flags non-2xx.

Signal: one warning-tier finding per dead link.

5-min manual fallback: in DevTools, right-click any internal link → “Open in new tab” → check the status code.

5. The signup flow actually works (the highest-stakes manual test)

The community repeatedly names the signup flow as the highest-impact place for launch-day failures to land. The static checkers (1-4, 6) don’t walk a flow; the audit can walk signup → success page, but may BLOCK on reCAPTCHA, OAuth without a Google account, or a payment-walled flow.

Why vibe coding causes it: the LLM wires the form to one endpoint and the post-submit flow to another, and they drift. The success page renders, but the auth cookie never sets, the session row never writes, the email goes to spam or never arrives. The signup looks like it worked; nothing actually worked.

The Prufa check: the flows analyzer plus the signup flow analyzer specifically. The LLM detects the form submit and the success page; plain code re-verifies the entry selector in the DOM. For the full walkthrough, see How Prufa verifies a signup flow. For the founder-facing version, see Test your signup flow before launch.

Signal: a flow report showing the form-submit → success- page transition, with the auth cookie set with the Secure flag.

5-min manual fallback: sign up with a fresh email; read the inbox; refresh in an incognito window and confirm the session holds. Email in spam → DNS records. Email missing → send code. Session doesn’t hold → cookie or session row.

6. JS console errors during page load

10 of 49 had this. A non-trivial JS error fires during initial render. The page may look fine, but something is broken underneath.

Why vibe coding causes it: the LLM generates a chain of imports and event handlers; one of them references a variable that doesn’t exist in the bundled output, or an event fires before its handler is registered.

The Prufa check: the console/errors analyzer plus LLM-judged advisory findings from the page-load walk.

Signal: any non-empty console error array in the report.

5-min manual fallback: open the site in a fresh Chrome window; look at the console; note every red line.

7. Payment webhooks fire (and update the database)

Community-sourced, not in the 49-audit set (the public-pages- only audit didn’t exercise auth or payments). But the r/vibecoding and r/nocode threads name it more than any other single failure: founders report the Stripe checkout.session.completed event arriving as a 200 OK without the database updating. Refunds, cancellations, failed payments, and disputes go entirely unhandled.

Why vibe coding causes it: the LLM generates the client-side checkout flow (the part the founder tests) and the server-side webhook handler (the part the founder thinks works because the client-side flow worked) as two separate features. They don’t get tested as a pair.

The Prufa check: the payments/webhook analyzer (or the flows analyzer’s Stripe extension). The audit walks the checkout end-to-end and asserts the database row exists after the webhook callback returns 200.

Signal: a critical-tier finding on the webhook callback returning 200 OK without the database update.

5-min manual fallback: trigger a test-mode checkout; watch the Stripe dashboard for the event; query the database for the matching row. If the event arrives but the row doesn’t, you have this bug.

8. Exposed API keys / secrets in client code

Community-sourced, but with a known price tag. The LLM copies an env var into client-side code where it gets shipped in the bundle and indexed by Google within hours.

Why vibe coding causes it: the LLM treats env-var reads as the same code path on the server and the client. It generates the read once; the bundler ships the resolved value to the client. The founder never sees the leak because they only test the server-side path. Founder reports on r/vibecoding and r/nocode name this as the most expensive vibe-coding failure to land in production (a Lovable founder publicly reported losing $2,500 in a single day to a Stripe secret shipped in client code, per research/2026-06-12-community-listening-vibe-coding.md).

The Prufa check: a regex pass over the served JS for known key prefixes — Stripe sk_live_, AWS AKIA, OpenAI sk-, GitHub ghp_, Slack xoxb-. Any match is a critical-tier finding.

Signal: a critical-tier finding on any matched secret prefix.

5-min manual fallback: View Source → Ctrl-F for sk_live_, AKIA, sk-, ghp_, xoxb-. If any match, you have this bug. Rotate the key immediately; the pre-rotation key is already in Google’s index.

9. The success state of the critical flow is actually persisted

Close sibling of item 5’s “the success redirect updates UI but the server-side state never updates” failure. The audit walks the flow and confirms the form-submit returned 200 and the success page rendered; the audit does not always confirm the post-flow state on the server side.

Why vibe coding causes it: the LLM’s then() chain catches the response and updates the client-side state; the server-side state update is in a separate code path that the LLM didn’t test end-to-end because it never runs together in the same process.

The Prufa check: the CaptureMeta record captures the cookies set during the flow, the response headers of the success page, and the network requests. If the success page returns 200 but no auth cookie is set, the finding is verified. The same field is what the manual fallback checks in DevTools.

Signal: a successful page render with no auth cookie on CaptureMeta.

5-min manual fallback: sign up, then open an incognito window and try to access an authenticated route. If it 401s, the bug is the cookie or the session row.

10. A second human (or a paid auditor) actually ran the manual checks above

The meta-check. The founder’s own tests are biased — they tested the happy path because they built the happy path. A second set of eyes catches what the builder can’t. The r/nocode “I rescue vibe coded apps for a living” thread names this as the highest-leverage thing a founder can do in the last hour before launch.

Why vibe coding causes it: the founder is the only person who has run the app. Every prior test was either synthetic or self-administered.

The Prufa check: there is no automated check for this. It is a process step, not a verification step.

5-min manual fallback: find one other person; ask them to sign up without telling them what to click. If they hit something the founder didn’t, the founder has something to fix before launch.

What the audit doesn’t do (honest limits)

The free audit can’t pass a reCAPTCHA, can’t exercise OAuth without a Google account, and can’t verify that an email actually arrived. Those are the parts the founder has to test themselves; the manual fallbacks above are the workaround.

The audit also can’t tell you the significance of a finding. “No canonical link” is a warning, not a critical — the cluster hub’s nine failure modes are ranked by frequency in the 49-audit set, but the ranking is a frequency observation, not a severity judgment. The hub ranks what breaks most often; this list follows that ranking. Your app’s severity ordering is yours.

What to do before you launch

Run the 10 items in order. The audit runs items 1-4, 6, and 8 automatically. The remaining four are the human-only ones. The 5-minute manual fallback for each item is the workaround for the cases the audit can’t see. If you build with a coding agent, each item here maps to a Prufa check that agent can execute — you can run the checklist from Gemini CLI inside the same loop you used to write the app.

The free audit on prufa.dev opens your entry URL, walks the critical paths, and reports the top findings in 60 seconds. No signup, no card. Run it before you ship; the audit is the first three items of this list, automated. If your agent does the building, set up Prufa in Kilo Code so the Kilo Code agent runs these ten verifications before shipping.

For the deeper flow walkthrough (item 5), the signup-flow deep-dive covers the same five failure modes with the engineering- level signal data. For the static-checker surface this list doesn’t cover, the pre-launch-qa hub covers the universal list. For the scored version of this checklist — six questions that turn the per-mode counts into a ship / fix-and-ship / hold verdict — see Is my vibe-coded app production ready?.

FAQ

What is a vibe coding testing checklist?

A short, runnable list of the specific things to verify in a vibe-coded app before launch — the failure modes AI coding workflows are most likely to introduce, each mapped to a check that catches it. The opposite of a 75-item generic list. This article’s 10 items are grounded in a June 2026 audit of 49 fresh launches.

How do you test a vibe coded app before launch?

Run a free 60-second audit on the entry URL — it walks the critical flows and reports the top findings. Combine that with the 5-minute manual checks in this list: the API-key View Source check, the signup-flow manual test, the second-human test, the network-tab observation. No single tool catches everything; the combination does.

What should I check before deploying a vibe coded app?

The 10 items in this article, in order. Items 1-4 and 6 are static-checker ones the audit runs in seconds. Items 5 and 7 are the flow-shaped ones (the audit walks them but may BLOCK on reCAPTCHA or OAuth without a Google account). Item 8 is the security check. Items 9-10 are the human-only ones. Each item’s 5-minute manual fallback is the workaround for the cases the audit can’t see.