Website launch checklist for indie hackers

In a June 2026 audit of 49 fresh web launches (every Show HN post from the previous 30 days that earned at least 10 points), 38 — 78% — shipped with at least one critical, machine-verified finding on day one (the full breakdown is here). Every launch checklist for indie hackers tells you to prep your Product Hunt post, warm your email list, and schedule your launch tweet. Almost none tell you to verify the product actually works. This one does, and it’s ordered by what actually breaks — not by what’s easy to check.

Here’s the list, at a glance, most-likely-to-break first:

1. Does your signup flow work end-to-end? — the highest-stakes item, the one no static checker can see.
2. Do analytics events actually fire on a real browser load? (the #1 finding in our 49-launch audit)
3. Are auth/session cookies set with the Secure attribute?
4. Any broken internal links in the nav, footer, or CTAs?
5. Is there a <link rel="canonical"> on your entry page?
6. Any JavaScript console errors on first load?
7. Does your payment webhook actually update the database? (if you charge — a manual check)
8. Has a second human run signup/checkout without your guidance?

Items 2–6 are the static surface a free 60-second audit catches automatically. Items 1, 7, and 8 are the ones you have to drive yourself — and item 1 is the one this whole article exists to argue you cannot skip.

The indie hacker launch checklist, ordered by what actually breaks

Each item below is a failure mode, how to verify it yourself in minutes, and — where it applies — the Prufa check that catches it. The ordering for items 2–6 comes from frequency in our June 2026 audit of 49 Show HN launches; items 1, 7, and 8 sit where they do by stakes, not frequency, because the public-pages audit couldn’t measure them (more on that below).

1. Does your signup flow actually work end-to-end?

This is first because it’s the one with the most to lose and the least chance of being caught by anything automatic you’ll run before launch. The success page renders, so it looks done — but the auth cookie never sets, the session row never writes, the welcome email lands in spam or never sends. Signup looks like it worked; nothing actually worked.

Verify it yourself: sign up with a fresh email. Read the inbox (check spam). Then open an incognito window and confirm the session holds on an authenticated route. Email in spam → fix DNS records. Session doesn’t hold → the cookie or the session row. This is the whole job of testing your signup flow before launch.

The Prufa angle: the flows analyzer detects the signup form and the success-page transition, and plain code re-verifies the entry element in the DOM. (Honest scope: the free audit detects and confirms the flow exists; it does not assert a server-side database row on its own — that’s the paid, walked-flow product. See item 7.)

2. Do analytics events actually fire on a real browser load?

The single most common critical finding in the 49-launch audit: 38 of 49 sites sent no analytics events at all on a real browser load. The script is in the HTML, the tag manager is configured, and nothing fires. Launch day is the one traffic spike you can never replay; data you don’t capture in that window is gone, not delayed.

Verify it yourself: open the site in a fresh browser with the network panel open, accept the consent banner, and filter for your analytics host. A page view should send a request before you touch anything. The nasty variant — the tag container loads but no event fires, which hit 3 more sites in the audit — shows up as the script downloading with no collect/track request following it.

The Prufa check: the tracking analyzer (backend/service/checks/tracking/) watches the browser’s actual network traffic, not the page source — that’s how it catches the container-loads-but- fires-nothing case a view-source check passes.

3. Are auth/session cookies set with the Secure attribute?

22 of the 49 audited sites set a cookie over HTTPS without the Secure flag. Some browsers will send it over plain HTTP anyway; some won’t. It’s the bug browsers tolerate until they don’t. A one-attribute fix sitting on nearly half the cohort.

Verify it yourself: DevTools → Application → Cookies. Inspect any auth-related cookie. The Secure column should be checked.

4. Any broken internal links in the nav, footer, or CTAs?

14 of 49 sites shipped a broken internal link. The ones that rot are the ones you never click yourself: the footer, the docs link, the pricing anchor that moved two redesigns ago. Visitors click them for you.

Verify it yourself: walk every nav and footer link once. In DevTools you can right-click a link → “Open in new tab” and check the status code. Two minutes.

5. Is there a <link rel="canonical"> on your entry page?

24 of 49 had no canonical link on the entry page, and 2 had a worse version — a canonical pointing at a different host, almost always a leftover from a template or staging config, which tells Google to index that other site instead of yours. The worst possible week to hand away your ranking is launch week.

Verify it yourself: view source on your homepage and search for rel="canonical". It should point at the page’s own URL on your own domain. The Prufa seo analyzer (backend/service/checks/seo/) flags both the missing case and the wrong-host case.

6. Any JavaScript console errors on first load?

10 of 49 threw a non-trivial JS error during initial render. The page can look fine while something underneath is broken — and visitors don’t file bug reports, they just leave.

Verify it yourself: open the site in a fresh browser window and watch the console on load. Note every red line.

7. Does your payment webhook actually update the database?

This one is a manual fallback — the public-pages audit can’t exercise it, and neither can any static checker. The common failure: the Stripe checkout.session.completed event arrives as a 200 OK, but the database row never updates. The client-side checkout (the part you test) and the server-side webhook handler (the part you assume works because checkout worked) were built as two separate features and never tested as a pair.

Verify it yourself: trigger a test-mode checkout, watch the Stripe dashboard for the event, then query your database for the matching row. If the event arrives but the row doesn’t, you’ve found it. This is exactly the kind of end-to-end assertion the paid walked-flow product automates — but before launch, do it by hand.

8. Has a second human run your signup/checkout without your guidance?

The meta-check, and the highest-leverage thing you can do in the last hour. Your own tests are biased: you tested the happy path because you built the happy path. A second set of eyes hits the edge you never considered.

Verify it yourself: find one other person, point them at your URL, and ask them to sign up (or buy) without telling them what to click. Whatever trips them up is your launch-day support queue, surfaced an hour early.

What every “indie hacker launch checklist” on Google misses

Search website launch checklist for indie hackers today and you get two honest, useful, and incomplete things (SERP re-checked 2026-06-19, research note).

The static-checks tool (the no-signup audit that ranks for the persona). It’s genuinely good at what it does: it checks 15+ issues in about 30 seconds across Technical Foundation (sitemap, robots.txt, meta tags, favicon), Performance & Security (SSL, page speed, mobile, Core Web Vitals), and SEO & Visibility (Open Graph, structured data, headings, alt text). If you want a fast read on the static surface, run it — that’s a real win. But it makes no mention of form submission, login, payments, webhooks, checkout, or session verification. It stops at the door of the app.

The marketing/distribution forum checklists (the Indie Hackers posts and Gumroad launch kits that fill the rest of the page). These are real launch-marketing playbooks: goals and metrics, launch date, prelaunch landing page, email list, build-in-public, Product Hunt prep. If you need to plan the announcement, they’re useful. But the product’s technical readiness is at most one bullet, and “does signup/checkout work” is absent.

The gap on the entire first page is the same one: functional-flow verification. Everything that ranks checks the static surface or the marketing plan. Nothing verifies that the signup or checkout flow actually works end-to-end. That’s the static-vs-functional split, and it’s the difference between “your favicon is fine” and “people can actually become customers.”

Why the signup flow is the thing you can’t skip

Here’s the honest part, and it’s the reason this article can say something no other QA tool’s blog can: zero of the 49-launch audit’s top findings were signup-flow findings. Not because those launches all had working signups — because the audit ran public pages only and never exercised auth or payments. The data has a hole exactly where the highest-stakes item lives.

That hole is the thesis. The most important thing to verify before launch is the one thing a static checker and a view-source pass structurally cannot see. You can confirm the favicon, the canonical, the OG tags, and the analytics tag with code that reads the page. You cannot confirm “a real person can sign up and pay” without walking the flow — driving the form, following the redirect, checking the cookie, reading the email. Static analysis ends where the interesting failures begin.

This is also where Prufa’s architecture matters, and where we’re careful about what we claim. The principle is the LLM navigates, plain code verifies: an LLM-backed agent finds and walks the flow (signup → success), but the verdict comes from deterministic code checking the DOM, the cookies, and the response — never from the model’s opinion. LLM-judged UX findings are advisory-tier only; that tier is an invariant, not a judgment call. In the free audit, that means the flows analyzer confirms the flow’s entry element is really in the DOM and surfaces it as advisory — free audits look, monitors walk, in the words of the analyzer’s own copy. The full walkthrough is in how Prufa verifies a signup flow. If you’re shipping an AI-assisted build, the vibe coding testing checklist covers the same flow gap for that specific case.

How to run a free functional check before you launch

The persona’s fastest entry point: paste your entry URL into the free 60-second audit on prufa.dev. No signup, no card. It’s the same no-friction shape as the static tool that ranks — but instead of stopping at the static surface, a real browser loads your pages, captures network traffic, cookies, console output, and response codes, and a fixed suite of deterministic checks grades the evidence. That covers items 2–6 above automatically — run the free launch audit and it verifies that whole set in one pass.

The honest limits, stated plainly so you know what’s still on you: the free audit can’t pass a reCAPTCHA, can’t complete OAuth without a Google account, and can’t confirm an email actually arrived. Those stay manual — they’re items 1, 7, and 8 on the list, and the by-hand steps under each are the workaround. No single tool catches everything; the audit plus the four manual checks does.

For the universal version of this list across the full static surface — not just the indie-hacker cut — see the full pre-launch QA checklist, ordered by what actually breaks. This article is the solo-founder persona spoke under it: same data, ordered for the person shipping alone with launch anxiety, and centered on the one item that costs you the most if you skip it. It anchors the indie hackers QA page, the home base for everything Prufa does for solo founders.

FAQ

What should I check before launching a side project?

Check the functional flows before the static surface. In a June 2026 audit of 49 fresh launches, 78% (38 of 49) shipped a critical bug on day one, the most common being analytics that captured no events. But the highest-stakes item — does signup or checkout work end-to-end — isn’t on any static checklist, because view-source can’t see a flow. Test that one by hand.

Do I need to test my signup flow before launch?

Yes — it’s the one item a static checker can’t verify for you. In our June 2026 audit of 49 launches, zero top findings were signup-flow findings, because the public-pages audit never exercised auth or payments. That absence is the point: the highest-stakes path is exactly the one no view-source check or static tool walks, so a human (or an agent that navigates) has to run it.

What do indie hackers forget before launch?

Not the favicon — the flow. Most launch checklists for indie hackers cover the static surface (sitemap, OG tags, SSL, speed) and the marketing plan (Product Hunt, email list). The thing that actually loses launch-day signups is a checkout or signup that 404s, drops the session cookie, or fires a webhook that never updates the database. None of those show up in view-source.

How do I test my website before launch as a solo founder?

Run a free 60-second audit on your entry URL for the static surface — analytics, cookies, canonical, broken links, console errors — then test the signup and checkout flows by hand. A single set of eyes is biased toward the happy path you built, so the last and highest-leverage step is having one other person sign up without your guidance and report what breaks.