We audited 49 Show HN launches. 38 had a critical bug on day one.

In June 2026 we pointed Prufa’s free audit at 50 products that had just launched on Show HN — every launch from the previous 30 days that earned at least 10 points. These are products at their moment of maximum attention: front page, real traffic, founders watching the comments.

The headline numbers, from the 49 audits that completed (one site couldn’t be reached by our runner):

• 100% of the 49 launches had at least one machine-verified finding.
• 78% — 38 of 49 — had at least one critical finding.
• 40 critical and 61 warning findings in total, every one verified by deterministic checks against captured browser evidence.

No site is named in this post. The point isn’t to embarrass anyone — it’s that these failures are systematic, and if these teams have them on launch day, you probably do too.

Methodology, briefly

Each site got the same audit a free Prufa run does: a real browser loads the public pages, captures network traffic, console output, cookies, and response codes, and a fixed suite of deterministic checks grades the evidence. Same input, same verdict. Every number below is from a code-verified check — no LLM opinions are counted anywhere in this data.

One honest caveat: our export keeps only the top findings per site, so the per-issue counts below are floors, not totals. The real numbers are equal or worse.

What actually breaks at website launch: the numbers

Sites affected (of 49)	Finding	Severity
38	No analytics events detected	critical
24	No canonical link on entry page	info
22	Cookies set without the Secure attribute	warning
14	Broken links	warning
12	No <h1> heading on entry page	info
11	No robots.txt	info
10	JavaScript console errors during page load	warning
10	Missing meta description	warning
8	Images missing alt text	info
7	Missing Open Graph tags	info
3	Tag container loads, but no analytics events fire	warning
2	Canonical URL pointing to a different host	critical

The most common launch bug: analytics that record nothing

The most common critical finding, by a wide margin: no analytics events detected. The page loads, the browser captures every outgoing request — and nothing resembling an analytics event leaves the page.

Think about what that means on launch day specifically. Front page of Hacker News is, for many of these products, the single largest traffic spike they will ever see. Which referrers converted, which pages people actually read, how many of those visitors signed up — for 38 of these 49 teams, that data simply doesn’t exist. Not sampled, not skewed: absent.

Three more sites had a subtler version: the tag container loads (so a quick “view source” check looks fine), but no events ever fire. That one is nasty precisely because it passes the eyeball test — the only way to catch it is to watch the network traffic, which is what our check does. If you’re checking your own site before you ship, here’s how to test your analytics before launch.

The rest of the list is the unglamorous stuff

Broken links (14 sites). Nobody clicks every link on their own site — especially footer links, docs links, and that one pricing anchor that moved two redesigns ago. Visitors do.

Console errors at page load (10 sites). Errors at load time often mean broken features visitors never report — they just leave. These ten sites shipped them to the HN front page.

Cookies without Secure (22 sites). A one-attribute fix, sitting on nearly half the cohort.

The canonical-to-wrong-host pair (2 sites, critical). Two sites shipped a <link rel="canonical"> pointing at a different domain — almost certainly a leftover from a template or staging config. That tag tells search engines “index that other site instead of me.” On launch week.

What we take from this

These aren’t careless teams. They got a product to Show HN and earned points doing it — which is exactly the constraint behind launch QA for indie hackers: one person can only click through so much before the front page hits. The pattern says something else: the surface area that needs verifying grows faster than anyone’s willingness to click through it — especially in the week before a launch, when everything is on fire.

None of the findings above require judgment to detect. Every one is a deterministic check against evidence a browser can capture: a response code, a network request that did or didn’t happen, an attribute on a cookie. Which is exactly why this should be automated — and why the LLM in our pipeline never grades results; plain code does.

How to fix the most common launch bugs, in order

If you only have an hour before you ship, spend it in this order — sequenced by how often each issue appeared across the 49 June 2026 launches and how expensive it is to discover after launch day.

1. Confirm analytics actually fire (38 of 49 sites failed this). Open your site in a fresh browser with the network panel open and filter for your analytics host. A page view should send a request before you touch anything. If the tag container loads but no event fires — the subtle variant that hit 3 more sites — you’ll see the script download but no collect/track request. This is first because launch-day traffic is the spike you can never replay: data you don’t capture in that window is gone, not delayed.

2. Check the canonical tag on every entry page (2 sites pointed at a different host — critical; 24 had none). View source and find <link rel="canonical">. It must point at the page’s own URL on your own domain. A canonical aimed at a staging or template host tells Google to index that site instead of yours — the worst possible week to hand away your ranking. No canonical at all is lower-stakes but still worth a one-line fix.

3. Click your own links, footer included (14 sites shipped broken ones). The links that rot are the ones you never click: footer, docs, the pricing anchor that moved in a redesign. Walk every navigation and footer link once. Two minutes; visitors do it for you otherwise.

4. Set Secure on your cookies (22 sites — nearly half). A single attribute on the cookies your framework sets. It costs nothing and clears the most common warning in the whole cohort.

5. Sweep the console for load-time errors (10 sites). Reload with the console open. Errors at page load usually mean a feature that silently doesn’t work — visitors won’t file a bug, they’ll just leave.

Everything below critical — meta descriptions, Open Graph tags, alt text, robots.txt, an <h1> — is worth fixing, but none of it costs you launch day the way a missing analytics event or a misdirected canonical does. Triage the critical pair first, then work down.

We later ran the same audit on a different cohort — 14 side-project launches from r/SideProject — and found the mirror image: zero critical bugs, but the same quiet flaws in nearly all of them.

We point it at ourselves too. On our own homepage it once caught our landing page contradicting itself — a meta tag and the page body disagreeing about the same number, the kind of quiet bug no single check catches.

This study is one half of our State of Launch QA 2026 report, which combines it with a second cohort of side-project launches.

We turned this dataset into a pre-launch checklist ordered by these failure rates, if you want the actionable version. The full nine-failure-mode write-up, aimed at the vibe-coding case specifically, lives in QA for vibe-coded apps: what actually breaks.

That’s the audit we ran on these 49 sites, and it’s free: paste a URL on the homepage, get the same machine-verified findings for your own site in about a minute. You can run the same free audit on your launch before your launch day, ideally.