Originally published at indielaunch.club
Something breaks on launch day. This isn't pessimism — according to a 2023 PagerDuty incident report, 74% of software teams experienced at least one critical deployment failure in the 12 months prior, and a significant portion of those happened on planned release days. A solid launch day checklist for developers doesn't prevent all fires; it makes sure you're not starting them yourself. The items below are drawn from actual launches — some clean, some not — and they're ordered by when they matter, not by how obvious they are.
The short answer for anyone skimming: run your pre-deployment checks the night before, freeze non-essential changes 24 hours out, have rollback ready before you ship, and monitor actively for the first 2–4 hours post-launch. Everything else in this list is context around those four anchors.
The Night Before: What Most Developers Skip
The 24 hours before a launch tend to get treated as buffer time — a chance to squeeze in one more fix, clean up a CSS edge case, rewrite that one endpoint that's been bothering you. Don't.
Freeze your codebase the night before. Not at 11pm. Earlier. Any change made within 12 hours of a launch is a change you haven't had time to observe in staging under anything resembling real traffic patterns. I've watched a one-line config change — genuinely trivial on its face — take down a payment flow on launch morning because it modified an environment variable that had a different default in production.
The night-before checklist:
- Staging parity check — Does your staging environment actually match production? Database version, environment variables, third-party API keys, CDN config. These diverge quietly over time.
- Smoke test the critical paths — Signup, login, core feature, payment if applicable. Not automated tests. Actually click through it.
- Confirm your rollback plan — Who runs it? How long does it take? Have you done it recently enough to know it works?
- Verify DNS TTL — If you're doing any DNS changes on launch day, and you haven't lowered TTL 48 hours in advance, you're going to wait a long time for propagation.
- Check SSL certificates — Embarrassingly common oversight. Check expiry dates.
- Backup current production state — Database snapshot. Before anything ships.
One thing I'd add that most checklists omit: send a heads-up to your support channel or inbox. Even if you have no users yet, if you're doing a Product Hunt launch or any kind of public distribution, front-load your communication so you're not writing emails while also monitoring logs.
Deployment: Slow Down When You Want to Speed Up
Launch morning has a particular adrenaline to it that makes people careless. You've been working toward this, and now the button is right there, and you just want to push it.
That urgency is where things go wrong.
The deployment sequence that's worked most reliably, in my experience, is: deploy to production before any public announcement goes out. Not simultaneously. Before. Give yourself a 15–30 minute window where the new version is live but unannounced, and run through your smoke test one more time in actual production. If something's broken, you catch it before anyone else does.
If you're launching on a platform like Product Hunt (and the mechanics of that process, including the timing of upvotes and how communities respond, are worth understanding separately through this breakdown of how to get upvotes on Product Hunt), your post going live should happen after your deployment is confirmed healthy, not at the same moment.
Deployment-day checklist:
- Run database migrations before traffic hits — Not during. Before.
- Clear caches deliberately — CDN, application-level, any edge caches. Don't assume your deployment pipeline handles this.
- Test in production with a real account — Not a test account with special flags. A normal user flow.
- Set feature flags to intended state — If you use feature flags, verify every one that's supposed to be on for launch is actually on.
- Check your error tracking tool is connected — Sentry, Datadog, whatever you use. I have absolutely deployed to an environment where the error tracking key was wrong and had no idea until an hour in.
Monitoring: The Part That Actually Tells You If It Worked
Most developers set up monitoring at some point and then forget to actually watch it on launch day.
For the first two hours after launch, someone needs to be watching your dashboards — not checking them every 20 minutes, actually watching. Error rate, response time, database query latency, memory and CPU if relevant. You're looking for trends, not just spikes. A slow drift upward in response time that started 40 minutes after launch is often more meaningful than a single spike.
Set up alerts before launch day, not on it. The threshold question is harder than it looks — too sensitive and you'll get noise that trains you to ignore alerts, too loose and you'll miss real problems. A rough starting point: alert when error rate exceeds 1% for more than 5 consecutive minutes, and when p95 response time crosses 2x your baseline.
The other thing worth having: a simple status page. Even a basic one-pager at status.yourdomain.com, even if you're a solo dev with 12 users. If something breaks and people can see you acknowledge it publicly, it changes the tone of every support conversation you'd otherwise have.
Distribution: Don't Launch and Disappear
Shipping is one action. Distribution is a sequence of actions that starts the moment you ship and continues for days afterward.
Most indie developers do the opposite of what works — they announce everywhere at once and then go quiet. The platforms where your launch gets traction are the ones where you're present in the comments, responding to questions, engaging with anyone who tries the product.
If you've built a structured plan around where and how you're distributing, the best places to launch a SaaS product worth prioritizing differ a lot by audience. Not all distribution platforms convert equally for all products.
A few specifics on the distribution checklist:
- Prepare your announcement copy in advance — Not a draft. Final copy, ready to paste. For Product Hunt, Hacker News, Reddit, your email list, your Twitter/X account. Writing these under pressure on launch day is a bad use of your attention. A well-crafted product launch announcement can be the difference between traction and silence.
- Schedule vs. manual posting — I prefer manual posting for most channels on launch day. Scheduled posts feel impersonal in a context where you need to be present.
- Have screenshots and a short demo video ready — Not a Loom you record 10 minutes before. An actual prepared asset.
- Tell your existing contacts personally — Not a mass email blast. If you have 30 people who said they'd be interested, message them individually. The conversion rate on personal outreach is dramatically higher.
The Comparison: Pre-Launch vs. Post-Launch Focus Areas
Task
Pre-Launch (Night Before)
Launch Day
Post-Launch (48 hours)
Code freeze
✓ Hard freeze
Hotfixes only
Resume normal
Staging check
Full parity check
Spot-check
N/A
Monitoring setup
Configure alerts
Watch actively
Review trends
Communication
Prepare all copy
Publish + respond
Follow-up emails
Rollback
Confirm ready
Keep on standby
Debrief if used
Distribution
Assets prepared
Post to channels
Engage comments
What to Do When Something Breaks Anyway
It will, at some point. The question is whether you have a practiced response or a panicked one.
A solo developer who launched a developer tool on Product Hunt — not a massive product, but one that had about 340 upvotes by end of day — had their signup flow break 90 minutes in because a third-party auth provider had a partial outage. They hadn't anticipated this dependency failing independently of their own code. The ones who handled it well had a fallback ready (magic link email), communicated it publicly within minutes, and kept their Product Hunt comments active throughout. The launch still ranked in the top 10 that day.
The point being: a well-maintained checklist doesn't eliminate this scenario, but it does mean you've already thought about your dependencies before launch day, not during it.
When something breaks:
- Don't announce it everywhere immediately — assess scope first (2 minutes max)
- Post a brief public acknowledgment if users are affected
- Decide rollback or hotfix based on severity, not preference
- Fix the communication before you fix the bug — people can wait for a fix, they can't wait for information
- Write a 3-sentence internal debrief afterward, even if it's just for yourself
Marketing Infrastructure You Need Live Before Launch
This section is shorter because the answer is less nuanced.
Before anything goes public: analytics tracking should be confirmed working (actually firing events, not just installed), your email capture should be tested end-to-end including the confirmation email, and your SEO basics should be in place — title tags, meta descriptions, canonical URLs, sitemap submitted. None of this requires a complex setup, but you'd be surprised how often one of these is broken on launch day.
If you're building any kind of long-term content distribution around your product, the infrastructure for that — your blog, your content process — matters more than most developer-focused launch content acknowledges. If that's relevant to your situation, the solo founder marketing tips and the best marketing channels for indie developers are worth reading before, not after, launch day.
FAQ
How many hours before launch should I stop making code changes?
At minimum, 12 hours — but 24 is safer. Any change pushed within 12 hours of a planned launch hasn't had time to be observed in staging under conditions that resemble production, and your cognitive bandwidth on launch morning is too stretched to properly assess risk.
What should be in a developer's rollback plan?
At minimum: a documented procedure for reverting to the previous deployment, a database backup from immediately before launch, a clear decision threshold for when to roll back versus hotfix, and at least one other person who knows how to run the rollback if you're unavailable. Untested rollback plans are close to useless.
Should I launch on a Monday or avoid it?
Avoid Fridays and the day before a major holiday. Mondays aren't ideal either if you want press coverage, since journalists and publications tend to get flooded on Mondays. Tuesday through Thursday, with Tuesday or Wednesday being the common consensus for Product Hunt specifically, gives you the best combination of team availability and audience attention.
How do I monitor for errors right after deployment?
You want real-time error tracking (Sentry is the most common option for smaller teams), server-side logging you can query quickly, and at least one dashboard showing request volume and response times. For the first two hours post-launch, watch these manually — don't rely on alerts alone, because misconfigured thresholds will either flood you with noise or miss early signals.
Do I need a status page if I'm a solo developer with a small user base?
If you're charging money or publicly launching to any audience: yes. It doesn't need to be elaborate. A simple page at status.yourdomain.com that you can update manually in 60 seconds is enough. Users are far more forgiving of outages when communication is visible and proactive.
Launch day is the wrong time to figure out what you should have figured out a week earlier. Go through this list when you still have room to act on it — that's the only version of this that works.
Top comments (0)