Most founders treat a startup launch checklist like a wedding seating chart. They obsess over font choices and ignore the fact that the venue doors might be locked. I have watched dozens of indie launches in real time. The ones that break are never missing a manifesto. They are missing a working password reset flow.
A good product launch checklist fits in your pocket, not a Notion dashboard. It covers only the items that will humiliate you in public if they fail. Everything else is pre-launch homework.
What Actually Breaks on Launch Day
Launch day traffic is not like test traffic. It arrives from Gmail threads, Twitter apps, and Hacker News readers using Safari on iPads. These users have never heard of you. They will not clear their cache. They will not retry a failed signup.
The most common public failures are boring. DNS records that resolve fine in San Francisco but lag in Frankfurt. OAuth redirect URIs that still point to localhost:3000. SSL certificates that look valid in Chrome but throw warnings on mobile Safari. These are not exotic edge cases. They are the default failures of a rushed launch.
Payment webhooks are another quiet killer. In test mode, Stripe happily sends events to http://localhost:4242/webhooks. In production, if your endpoint returns a 302 redirect or a 500 error, customers get charged while your app sits there clueless. You will not notice this until someone emails you in anger.
Email is the third silent assassin. You send a thousand welcome emails from a fresh domain. Gmail decides you look suspicious. Your users check their spam folders, find nothing, and assume your product is broken. No error log will show this. You have to test it manually.
If you have not run your signup flow in a cold incognito window on a cell network, you have not tested your signup flow.
The 8-Item Startup Launch Checklist
This is your startup launch checklist. Eight items. No filler. If every box is green, you are safe to post the link.
Cold-browser signup. Open an incognito window. Sign up with a real email. Verify the address. Log out. Log back in. If any step fails, stop.
External DNS check. Run
dig +short yourdomain.comfrom a different network than your office. Use your phone's tethering. Make sure it resolves to your production IP, not a parking page.SSL on all entry points. Hit
https://,http://, andwww.variants. Every combination should show a padlock. No mixed-content warnings.OAuth URI match. Check Google Cloud Console, GitHub App settings, or whatever provider you use. The redirect URI must match production exactly.
https://myapp.com/auth/callbackis not the same ashttps://www.myapp.com/auth/callback.Payment webhook 200. Trigger a real event in Stripe's test mode pointing at your production webhook URL. Check the Stripe dashboard for a green
200 OK. Do not trust your local logs.Email deliverability. Send a welcome email to a fresh Gmail address and a fresh Outlook address. Check spam folders. Set up
SPF,DKIM, andDMARCrecords if you have not already.Database connection limit. Check your Postgres or MySQL connection pool size. Make sure it matches what your hosting platform actually allows. Render's free tier and Railway's starter tier have hard caps. Exceeding them creates 500 errors that look like code bugs.
Error alerting is loud. Confirm that Sentry, LogRocket, or Honeybadger can reach your phone. Trigger a test error. If your phone does not buzz, fix it before you post.
That is the whole product launch checklist. If these eight pass, your house is in order. Polish comes later.
Domain & DNS: The Silent Killers
Since you are already using namemyapp, you care about domains. Here is where most indie hackers slip. You buy the perfect name, point it at Vercel or Railway, and assume the internet will cooperate. It does not always.
| Failure mode | Quick test | Tool | Fix time |
|---|---|---|---|
| DNS propagation lag | dig +short from mobile data |
dig or whatsmydns.net |
0 min if pre-checked |
SSL cert not covering www |
Visit www. variant |
Browser padlock icon | 5 min in Vercel dashboard |
| Registrar parking page | Open domain in fresh browser | Incognito window | Update A/AAAA records |
| Email auth records missing | Check TXT records |
dig TXT yourdomain.com |
Add SPF/DKIM/DMARC |
The registrar matters less than the timing. If you switch nameservers at 9 AM to "get it right before the post," you are gambling with global DNS caches. TTLs might be 300 seconds or 86400 seconds. You do not control which resolver your visitor's ISP uses.
Here is a five-minute preflight script I keep in every project root:
#!/bin/bash
DOMAIN="yourdomain.com"
echo "Checking DNS..."
dig +short $DOMAIN | grep -E "[0-9]+\.[0-9]+" || echo "DNS FAIL"
echo "Checking HTTPS..."
curl -s -o /dev/null -w "%{http_code}" https://$DOMAIN/health
echo "Checking email SPF..."
dig TXT $DOMAIN | grep "v=spf1" || echo "SPF MISSING"
Run this from a coffee shop Wi-Fi. If it passes there, your domain is actually live.
Do not transfer or register a new domain on launch morning. ICANN holds, registry locks, and propagation delays are real. Lock your domain at least 72 hours before you post.
A Launch Day Checklist for the Final Hour
You have passed the eight items. Your domain is stable. Now you need a launch day checklist for the human side of the event.
Keep these three browser tabs pinned:
- Your error monitoring dashboard. Refresh it after every traffic spike.
- Your payment processor dashboard. Watch for failed webhooks in real time.
- Your support channel. Whether it is a Twitter DM, a Discord thread, or a Plain inbox, be there.
Post from an account where people can reach you. Nothing says "I am not ready" like a Show HN thread where the founder disappears for three hours because they are debugging a database lock.
Have a rollback plan that does not require a deploy. An environment variable flip is faster than a git revert. If you use a feature flag tool like LaunchDarkly or a simple .env toggle, you can kill a broken feature in seconds.
One last thing. Write your "we are live" post before you are live. Draft it in a text file. Launch hour adrenaline makes everyone sound either robotic or drunk. A pre-written post keeps you calm.
FAQ
Do I need a product launch checklist if I'm just posting on Hacker News?
Yes. A small launch is still a public launch. Hacker News traffic is unpredictable. A post that hits the front page can send ten thousand visitors in an hour. If your signup flow breaks, you are not getting a second chance at that crowd. A short product launch checklist prevents a five-minute fix from becoming a public embarrassment.
How early should I lock down my domain before launch?
Lock it at least one week before. You need time for DNS propagation, SSL certificate issuance, and email reputation warming. If you are using a new domain for transactional email, send a few dozen messages to personal accounts first. Gmail and Outlook need to see consistent, low-volume behavior before they trust you. A last-minute purchase is a gamble.
What if my payment webhooks fail silently?
Check your payment processor's dashboard first. Stripe shows webhook delivery attempts with full response bodies. Look for 502 or 302 status codes. A 302 usually means your route requires authentication or redirects to a login page. A 502 often means your server crashed.
Fix the endpoint, then use the Stripe CLI to replay the event with stripe trigger payment_intent.succeeded. Do not ask the customer to retry their card.