State of Launch QA 2026: we audited 63 launches. Here's what breaks.

We ran real-browser QA audits on 63 product launches (Show HN + r/SideProject) in June 2026. 78% recorded zero analytics on launch day. The full data.

Across June 2026 we pointed Prufa’s free audit at 63 product launches — 49 from Show HN and 14 from r/SideProject — and graded each with the same deterministic checks. This post is the combined data: what actually breaks when real products go live, from two cohorts that failed in opposite ways.

The one number that unifies both: 78% of the 63 launches (49 sites) recorded zero analytics events on launch day. 100% shipped at least one machine-verified issue. Every figure here is from a code-verified check against captured browser evidence — no LLM opinions are counted anywhere.

The headline numbers

  • 63 launches audited (of 70 attempted: 1 unreachable, 4 blocked by bot protection, 2 timed out).
  • 100% had at least one machine-verified finding.
  • 49 of 63 (78%) sent no analytics events at all — the single most common finding in both cohorts.
  • 38 of 63 (60%) had at least one critical finding — but that number is cohort-split in a way that’s the most interesting part of the data.

Two cohorts, opposite failure modes

The Show HN cohort failed loudly. The r/SideProject cohort failed quietly. Same audit, same checks — very different shapes.

Show HN (49 sites)r/SideProject (14 sites)
At least one critical finding78% (38)0%
No analytics events78% (38)79% (11)
No canonical on entry page49% (24)57% (8)
Serious accessibility violations79% (11)
No Content-Security-Policy79% (11)
Slow mobile LCP (>4s)64% (9)
Broken links29% (14)
Canonical pointing at a different host4% (2, critical)0%

The Show HN launches shipped flow-breaking failures: dead analytics tags, broken links, and two sites whose <link rel="canonical"> pointed at a different domain — telling search engines to index someone else’s site during launch week. The side-project launches had none of that. Not one critical. By the measure that matters most on launch day — does the core thing work — they shipped clean.

And yet all 14 had findings, one tier down, in a layer so consistent it reads like a shared checklist nobody handed out: no analytics, no security headers, serious accessibility violations, sub-4-second mobile paints. “Nothing is broken” and “nothing is leaking” turned out to be very different claims.

The finding that shows up everywhere: flying blind

The most common issue in both cohorts, by a wide margin, is analytics that record nothing. The page loads, the browser captures every outgoing request, and no analytics beacon ever leaves it.

Think about the timing. Launch day — front page of Hacker News, or a hot r/SideProject post — is the single largest, clearest traffic signal these products will get for weeks. Which referrer converted, which screenshot made people click, how many visitors reached signup: for 49 of these 63 teams, that data was never recorded. Not sampled, not skewed — absent. And launch traffic is the one spike you can never replay.

A subtler variant hit a few sites in the Show HN cohort: the tag container loads (so a “view source” check looks fine) but no event ever fires. That one passes the eyeball test — the only way to catch it is to watch the network traffic. If you want to check your own before you ship, here’s how to test your analytics before launch.

The quiet tax: security, accessibility, mobile

The side-project cohort exposed the flaws that don’t page you but cap your growth:

  • Security headers nobody adds. 11 of 14 had no Content-Security-Policy and could be embedded in an iframe by any site (the clickjacking setup). Each is a one-line config fix.
  • Accessibility. 11 of 14 had serious accessibility violations — missing form labels, insufficient contrast, controls with no accessible name. A button a screen reader can’t name is usually confusing to everyone.
  • Mobile. 12 of 14 had tap targets under 24px and 9 took over four seconds to paint on mobile — one took 18.5 seconds. Most launch traffic from a social post is mobile.
  • The AEO gap. 11 of 14 shipped no llms.txt and 7 had no structured data. As more “what’s the best tool for…” traffic resolves inside ChatGPT, Perplexity, and Google’s AI overviews, a launch with neither is invisible to the channel growing fastest.

Methodology

Each site got the same audit a free Prufa run does: a real browser loads the public pages and captures network traffic, console output, response codes, headers, cookies, and the rendered DOM; a fixed suite of deterministic checks then grades that evidence. Same input, same verdict.

Three honest caveats:

  1. Deterministic only. Every number here is from a code-verified check. The audit also produces LLM-written UX observations, but those are advisory and counted nowhere in this data — plain code grades results, not the model.
  2. Counts are floors. Our export keeps only the top findings per site, so per-issue counts are lower bounds, not totals. The real numbers are equal or worse.
  3. Small samples, two sources. 49 + 14 sites from two communities in one month. Treat as directional, not census.

No site is named anywhere. The point isn’t to embarrass anyone — these are teams that got real products live and earned attention doing it. The point is that the failures are systematic: the surface area that needs verifying grows faster than any one founder’s willingness to click through it, especially in the week before launch when everything is on fire. None of these findings requires judgment to detect — a request that did or didn’t happen, a header that is or isn’t present, a response code — which is exactly why it should be automated.

The source studies

This report combines two write-ups, each with its full per-finding table:

If you want the actionable version, the failure modes are ordered into a pre-launch QA checklist. And the audit itself is free: paste a URL on the homepage and get the same machine-verified findings for your own launch in about a minute — ideally before you post it.

Cite this study

Prufa (2026). State of Launch QA 2026: an audit of 63 product launches. https://prufa.dev/blog/engineering/state-of-launch-qa-2026/

Data collected June 2026 across 49 Show HN launches and 14 r/SideProject launches. Figures are from deterministic browser-evidence checks. Journalists and writers: the underlying per-finding tables are in the two linked source studies, and we’re happy to answer methodology questions — reach us via prufa.dev.

Frequently asked questions

How many websites launch with bugs?

In our June 2026 audits of 63 product launches (49 from Show HN, 14 from r/SideProject), 100% shipped at least one machine-verified issue and 78% recorded zero analytics events on launch day. Among the Show HN cohort specifically, 78% (38 of 49) had at least one critical finding; the r/SideProject cohort had zero criticals but the same quiet flaws in nearly all 14 sites.

What is the most common bug on newly launched websites?

Broken or absent analytics. Across the 63 launches we audited in June 2026, 49 (78%) sent no analytics events at all — the page loaded, but no tracking request ever left it. It was the most common finding in both cohorts, which means most teams captured no data on the single biggest traffic day they'll have for weeks.

Is this just a Lighthouse score?

No. Each site was loaded in a real browser and a fixed suite of deterministic checks graded the captured evidence — network requests, response codes, headers, rendered DOM. Lighthouse scores one page against a rubric; this checks whether specific things are true (did an analytics request leave the page? does an unknown URL return 404?) and reports each as a discrete, verifiable finding. No LLM opinion is counted anywhere in the data.