Is my vibe-coded app production ready? a scored assessment from 49 launches

You have a vibe-coded web app. You want to ship. You don’t want to ship and find out on launch day that the analytics never fired, or the cookies are missing the Secure flag, or the signup flow silently 500s on a fresh email. You want a verdict — a number, a band, a “ship now” or “hold and fix” — before you press the button.

This article is that verdict.

In June 2026 we ran an automated audit on 49 fresh web launches — Show HN products in the prior 30 days with at least 10 points, each one opened in a real browser, with the public pages exercised and the network traffic captured. The audit is the same one the free 60-second audit on prufa.dev runs against your URL: it walks the critical paths, runs the static checks, and reports the verified findings — the ones the deterministic layer caught, not the ones an LLM thought it caught. The hub catalogs the nine failure modes the audit caught, ordered by how often each one showed up. The 10-item testing checklist is the actionable version: ten things to verify, each tied to a real Prufa check.

This article is the third layer of the same cluster, and it answers a different question: is your app ready, or isn’t it?

The 49-launch distribution, in one number

Of the 49 fresh launches we audited, 38 (78%) had at least one critical verified finding on day one. The other 11 (22.4%) had no criticals. That 78% is the headline number; the shape behind it is what makes the verdict work.

The shape: most apps with a critical had exactly one. Not five, not ten — one. Of the 49, 36 (73.5%) had exactly one critical finding, 2 (4.1%) had two, and 0 had three or more. The distribution is bimodal at the low end: either you have zero criticals or you have one, and “many” is essentially never seen in the data we have.

That is good news and bad news.

The good news: the typical failure is one bug, not a list. If you score 1 on this assessment, you can find the bug and fix it in an afternoon. The bad news: the typical failure is invisible — it doesn’t crash the page, doesn’t show up in the dev console, doesn’t trigger a warning banner. It’s the analytics beacon that fires zero events after the consent banner is accepted. It’s the auth cookie without Secure. It’s the canonical link pointing at a different host. These are the bugs the founder never notices because they happen at the edges — the parts of the app the founder didn’t manually test because the founder wrote them.

The scored assessment below is six questions, one per failure mode, weighted by how often that mode shows up in the 49 audits. Each question is 0 to 2 points. The total is 0 to 12. The verdict band maps to the same 49-launch distribution above: 0-2 = ship now (you’re in the 22% with no criticals), 3-5 = ship after fixing the top mode (you’re in the 73% with exactly one), 6-8 = hold and fix (you’re in the 4% with two), 9-12 = do not ship (the 0% in our data — but the rule stays because the cost of getting it wrong is asymmetric).

The complete list of all 49 sites, with their per-site finding counts, is in outbound/leads.csv (the harvest that produced this distribution). Every score below traces to a real check in backend/service/checks/ — the same checks the audit runs.

How to score yourself

For each of the six questions below:

• 0 if your app passes the check (or the audit reports a verified 0 for that mode).
• 1 if the audit reports a warning-tier finding, a partial pass, or the audit was blocked (reCAPTCHA, OAuth without a Google account) and you haven’t manually verified the case the audit couldn’t see.
• 2 if the audit reports a verified critical-tier finding, or the manual fallback failed, or you couldn’t find the thing being checked.

Sum the six scores. The band is your verdict. If you haven’t already, run the free 60-second audit on your URL first — it returns the verified findings the scores below map to, so the assessment is anchored to real evidence rather than memory.

One honest limit before the questions: this assessment is about the parts of your app the deterministic check layer can see. The audit walks public pages, watches the network, inspects the cookies, and reports what the browser experienced. It does not see your server logs, your database state, your Stripe webhook delivery, or your email-actually- arrived. Questions 1-4 are static-checker ones the audit runs in seconds. Question 5 is the flow-shaped one the audit walks but may BLOCK on. Question 6 is the human-only meta-check. The limits section below lists what the score doesn’t cover.

The six questions

1. Are analytics events firing on a real browser load?

0 if your dashboard shows real events after you accept the consent banner and click around for 30 seconds. 1 if the audit BLOCKED (the consent banner wasn’t auto-acceptable) and you haven’t manually verified that the beacon fires post-consent. 2 if your dashboard shows zero events, or the audit reported tracking.no_events as a verified critical.

The 49-audit data: 38 of 49 sites (78%) had this as a verified critical — the most striking finding in the dataset. The script is in the HTML. The tag manager is configured. Nothing fires. The cause is almost always a consent state the LLM generated separately from the analytics tag and never tested together: the tag only fires after consent = accepted, but the founder (and the audit) test before consent. In production the same audit runs after a synthetic consent acceptance and sees nothing — the tag manager isn’t reading the consent state, or the event name doesn’t match what the dashboard is listening for, or dataLayer.push is being swallowed by an error handler.

The Prufa check that catches this: 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 (CDP attached, network activity observed), it’s a verified critical. The capture_trustworthy invariant on CaptureMeta is what 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 open the network tab and filter by your analytics vendor’s hostname. If zero requests, score 2.

2. Are cookies set with the Secure attribute?

0 if every auth-related cookie in DevTools → Application → Cookies has the Secure column checked. 1 if some non-auth cookies are missing it (warning-tier, the audit will surface this as cookies.secure_missing). 2 if any auth cookie is missing it, or you ship the session cookie without HttpOnly as well.

The 49-audit data: 22 of 49 sites (45%) had this. The warning fires for the consent and tracking analyzers both — the cookies list on PageSnapshot is inspected by both, and the Secure flag is the one attribute the LLM most often forgets because the dev environment is HTTP, where the flag never matters locally. Browsers “tolerate” this bug inconsistently: some send the cookie on HTTP anyway, some don’t. The behavior isn’t deterministic across user agents, which is exactly the class of bug a deterministic check is for.

5-min manual fallback: DevTools → Application → Cookies. Click any cookie in the list. The Secure column should be a checkmark. The session cookie, the auth cookie, the CSRF token — all three.

3. Is the canonical link on the entry page set correctly?

0 if <link rel="canonical"> is present and points to your own host, with the URL you want indexed. 1 if the canonical is present but the URL is self-referential only (a missing https://, a trailing-slash mismatch, or a query string the canonical doesn’t include). 2 if the canonical is missing, or it points to a different host.

The 49-audit data: 24 of 49 sites (49%) had a missing or incorrect canonical as an info-tier finding; 2 of those 24 had a canonical pointing to a different host (a critical-tier finding the audit names-and-shames separately because the impact is “your page will not be indexed under your domain”). Google picks a URL on its own when the canonical is missing — usually the one with the most inbound links, which may not be the one you want indexed. When the canonical points to a different host, Google treats that host as the authoritative version. You have just given your search traffic to someone else.

5-min manual fallback: view source on the homepage, search for rel="canonical". If missing, add it. If present, confirm the host is yours and the path is what you want indexed.

4. Are the internal links 2xx?

0 if every link in the nav, footer, and the home page’s CTA surfaces returns 200. 1 if any 404 lives in the nav or footer (the audit flags non-2xx as a warning per link; treat the worst one as your score). 2 if a CTA in a high-traffic page is broken — the link that drives the signup button, the link from the pricing page to the signup page, the link from a blog post’s “start the audit” call to action.

The 49-audit data: 14 of 49 sites (29%) had this. 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. 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.

5-min manual fallback: in DevTools, right-click any internal link → “Open in new tab” → check the status code. Sample ten links. Pay extra attention to the nav, the footer, and any CTA button.

5. Does the signup flow actually work end-to-end?

0 if a fresh-email signup, on a real browser, completes the form-submit → success-page transition, sets the auth cookie with Secure, and the incognito-window re-load holds the session. 1 if the audit BLOCKED on reCAPTCHA or OAuth-without-a- Google-account, and you haven’t manually verified the flow. 2 if the form submits but the success page doesn’t set the auth cookie, or the email goes to spam, or the session doesn’t hold in an incognito window.

The 49-audit data: not directly in the per-mode counts (the public-pages-only audit didn’t exercise auth), but the community repeatedly names the signup flow as the highest-impact place for launch-day failures to land — and the signup-flow spoke catalogs the five things that break it. The engineering post How Prufa verifies a signup flow is the depth-walk: how the LLM detects the flow entry, how plain code re-verifies the DOM, how CaptureMeta records the cookies set during the flow.

The Prufa check: the flows analyzer plus the signup flow analyzer specifically. For the actionable 10-item list that includes this one, see the vibe coding testing checklist (item 5).

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. Did a second human run the manual checks above?

0 if at least one other person ran the audit, scored themselves against this rubric, and re-ran the manual fallbacks for any 1 or 2 you scored. 1 if only you ran the audit + the manual fallbacks. 2 if no one ran them.

This is the meta-check. There is no automated check for it. The r/nocode “I rescue vibe coded apps for a living” thread names it as the highest-leverage thing a founder can do in the last hour before launch — not because a second human catches different things, but because a second human is unbiased in a way the builder can’t be. You tested the happy path because you built the happy path. The second human doesn’t know what the happy path is. They click the button that doesn’t say what they expected. The form asks for a phone number and they don’t have one. The success page loads but the “continue” button is below the fold and they don’t scroll.

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

The verdict

Sum the six scores. The total is 0 to 12.

Total	Verdict	What it maps to in the 49-audit set
0-2	Ship now.	The 11 of 49 (22.4%) with no critical findings. You’re in the tail. Run the audit one more time on a fresh browser to confirm the score, then ship.
3-5	Ship after fixing the top mode.	The 36 of 49 (73.5%) with exactly one critical. Find the question you scored 1 or 2 on, fix the underlying bug, re-run the audit, then ship. The bug is real, the fix is bounded.
6-8	Hold and fix.	The 2 of 49 (4.1%) with two or more criticals. Multiple things broke. Don’t ship. Spend a day fixing the top three modes, re-run the audit, re-score.
9-12	Do not ship.	The 0 of 49 (0%) in our dataset with three or more critical findings — the tail is empty in the data we have. The reason the rule stays: a score this high means multiple categories of your app are broken, and shipping compounds the cost. The next step isn’t “fix it faster,” it’s “rebuild the broken parts.”

The 73.5% band is where most production-readiness answers land. If you score 3-5, the work is concrete: pick the question with the highest score, fix the underlying mode, re-run the audit — and if that’s where you built, you can re-run readiness checks from Windsurf without leaving the editor. The 10-item testing checklist is the actionable version of the same data, in priority order; the first item (no analytics events) is the one that accounts for 38 of the 49 sites in our dataset.

If you scored 6-8 or 9-12, the work is not a one-day fix. The audit will tell you which two modes are broken; both need attention. Re-score after the fixes.

What the audit doesn’t do (honest limits)

The free audit on prufa.dev can’t pass a reCAPTCHA, can’t exercise OAuth without a Google account, and can’t verify that an email actually arrived. Those three limits are load-bearing: the audit walks flows but may BLOCK on the auth surface, and a BLOCK is scored as a 1 (you have to manually verify what the audit couldn’t see). The 5-minute manual fallbacks above are the workaround for each.

The audit also doesn’t see payment webhooks, server-side state, or any side effect the browser can’t observe. The vibe coding testing checklist items 7 and 9 are the parts the audit doesn’t cover (payment webhooks, post-flow state persistence) and the signup-flow spoke is the depth on the highest-stakes single flow.

The score is your self-administered score, not a third-party audit. A founder who scores 0 on every question should treat it as “I’m in the 22%”; a founder who scores 12 should treat it as “I’m in the 0% with 3+ criticals, the cost of getting it wrong is asymmetric, do not ship.” The data is the benchmark, not a moral judgment.

And the dataset itself has limits. n=49 is small. The sample is Show HN launches with at least 10 points, which is a specific corner of the population — apps that did well enough to be voted up, not the long tail of apps that shipped and weren’t seen. The failures the audit catches are the ones in the public pages; apps with more critical findings may simply not have shown up in the Show HN list in the first place. The bimodal shape (0 or 1 critical, thin upper tail) is the real shape of the data we have, but it’s not the shape of “vibe-coded apps generally.” The 49 sites are launches generally, not vibe-coded apps specifically — state it.

What to do before you launch

Run the audit on your entry URL. The free audit at prufa.dev runs questions 1-4 automatically (the static-checker surface). Question 5 is the flow-shaped one the audit walks but may BLOCK on. Question 6 is the human-only meta-check.

If you score 0-2: ship. If you score 3-5: fix the top mode, re-run, then ship. If you score 6-8: hold, fix the top two modes, re-score. If you score 9-12: do not ship.

The audit becomes the scoring tool. The rubric above is the scoring sheet. The two together replace the “vibes-based” launch decision with a data-anchored one.

For the catalog of the nine failure modes this assessment is grounded in, see QA for vibe-coded apps: what actually breaks. For the actionable 10-item list (each item: failure mode → Prufa check → signal → 5-min manual fallback), see Vibe coding testing checklist. For the depth on the highest-stakes single flow, see Test your signup flow before launch.

FAQ

What percentage of vibe coded apps are production ready?

In our June 2026 audit of 49 fresh launches, 11 (22.4%) had no critical verified findings; 36 (73.5%) had exactly one; 2 (4.1%) had two; 0 (0%) had three or more. Production-ready in the sense of “no criticals” is achievable for ~22% of fresh launches in our sample. Production-ready in the sense of “no findings of any tier” is ~0% — every site had at least one warning or info finding. The verdict band the scored assessment maps to (0-2 = ship, 3-5 = fix and ship, 6-8 = hold, 9-12 = do not ship) is the operational version of this distribution.

Is vibe coding production ready for serious apps?

For internal tools and MVPs, yes. For low-risk public apps with the verification layer in place (the deterministic check surface that catches the failure modes above), yes. For payment / auth / data apps, only after the verification layer is in place and the audit is clean. The architectural pattern: the LLM navigates, plain code verifies — same trust boundary the hub walks through in the verification-architecture section. The scoring rubric in this article gives the founder the answer for their app, not a category-level verdict.

What should I check before shipping a vibe coded app?

The six questions in this article, in order: analytics events (item 1, 38/49), cookie Secure flag (item 2, 22/49), canonical link (item 3, 24/49), internal links (item 4, 14/49), signup flow (item 5, community-named highest- impact), second human (item 6, the meta-check). For the actionable 10-item list — each tied to a real Prufa check plus a 5-minute manual fallback — see the vibe coding testing checklist. The 6 questions above are the scoring; the 10-item list is the actionable subset; the hub is the full catalog.