Product Launch Checklist for Dev Tools: Every Step, Phase by Phase
A product launch checklist for developer tools and SaaS, grouped by phase from week −8 to week 4, with an owner and a done-when test for every launch step.
Product Launch Checklist for Dev Tools: Every Step, Phase by Phase
Quick answer: A usable product launch checklist has five phases: foundations (T−8 to T−5 weeks), assets and technical readiness (T−4 to T−2), a freeze-and-rehearse week, launch day, and four weeks of follow-up. Give every task one owner and a done-when test, cut rows that don't apply, and don't stop at launch day: the post-launch phase is where launch traffic turns into users.
A product launch checklist is only useful if every line has an owner and a clear "done when" test. "Prepare marketing" is a wish; "OG image renders correctly in a Slack and X preview" is a task you can tick off.
This checklist is built for developer tools and small SaaS teams. It runs from eight weeks before launch to four weeks after, grouped by phase, so you can copy it into your issue tracker and treat launch planning like any other project with a deadline. For the strategy behind it (what to launch, which channels, how to size the effort), read our product launch strategy playbook first. This page is the operational side.
How to use this checklist
Work through it in three passes:
- Cut. Delete rows that don't apply. A CLI tool with no billing doesn't need a payment test. A feature release doesn't need a press list.
- Assign. Put one name on every remaining row. On a two-person team, that still matters: "both of us" means neither.
- Date. Turn the relative weeks (T−8, T−4, T−1) into real dates, working backwards from launch day.
Each table below has a "Done when" column. If you can't write a done-when test for a task, it's too vague to be on a launch roadmap. Rewrite it until you can.
Turning rows into tickets
Each row becomes one issue. A consistent format makes the launch board readable at a glance. This is the structure we suggest:
| Field | Example |
|---|---|
| Title | [Launch T−3] Open Graph image and tags |
| Owner | One person, never a team |
| Due date | The real calendar date for T−3 weeks |
| Done when | Image is at least 1200 × 630 px; preview renders in a link debugger for the landing page and launch post |
| Blocks | Launch post published; social thread drafted |
| Label | launch, plus content or technical |
The "Blocks" field is the one teams skip, and the one that matters. Write it, and the critical path shows up on its own: the no-signup demo blocks the Show HN post, the billing test blocks the pricing page, the activation event blocks the week-4 review. Anything that blocks three or more tickets should start this week.
Phase 1: Foundations (T−8 to T−5 weeks)
These are the slow steps to launch a new product. They depend on decisions, not effort, so start them first.
| Task | Done when |
|---|---|
| Write the one-sentence pitch: user, job, difference | Three people outside the team can repeat it back without notes |
| Decide the launch tier (new product, major feature, minor update) | Tier is written in the plan and matches the effort budget |
| Pick the primary launch date and two or three channels | Date is on the calendar; each channel's rules have been read by the owner |
| Set up a waitlist or early-access list | Signup form works, confirmation email arrives, list is exportable |
| Define the activation event | One event (first API call, first project, first deploy) is named and tracked |
| Recruit 10–20 early users | They have access and have agreed to give feedback before launch |
| Start a public changelog | At least two entries are live |
| Authenticate your sending domain | SPF, DKIM and DMARC records pass for the domain your launch emails come from |
| Publish a privacy policy and terms | Linked from the signup form and footer, and they describe what you actually collect |
Email authentication is a foundations task because DNS changes and deliverability problems take time to sort out, and your waitlist email is the highest-converting message you'll send on launch day. Google's email sender guidelines have required all senders to Gmail personal accounts to set up SPF or DKIM since February 1, 2024. Senders of more than 5,000 messages a day need SPF, DKIM and DMARC, one-click unsubscribe on marketing messages, and a spam rate in Postmaster Tools below 0.30%. Google recommends staying below 0.10%.
A small waitlist won't hit 5,000 messages a day, but meeting the bulk-sender bar anyway costs little: set up all three records and use a sending service that supports one-click unsubscribe.
Channel rules belong in this phase because they change what you build. Show HN requires something people can try, and treats sign-up and landing pages as off topic. If Hacker News is a primary channel, a no-signup demo becomes a week −8 engineering task, not a week −1 marketing one.
Phase 2: Assets and site readiness (T−4 to T−2 weeks)
This is where most of the product launch process happens. Split it into content and technical work so two people can run in parallel.
Content assets
| Task | Done when |
|---|---|
| Launch post on your own blog | Covers problem, solution, pricing and what's next; reviewed by someone outside the team |
| Quickstart or getting-started doc | A new user reaches a first result in under five minutes, timed |
| Screenshots and a short demo video or GIF | Three to four screenshots at consistent size; video under 90 seconds |
| First comment drafted for each channel | Plain language, explains why you built it, no ad copy |
| FAQ section on the landing page | Answers pricing, data handling, self-hosting and limits |
| Email to waitlist and existing users | Written, scheduled, test-sent to yourself |
The launch post is the hub. Every channel post, email and social thread links to it, so spend the most editing time here. Run the draft through a heading structure analyzer to catch skipped levels before it goes live.
Technical readiness
| Task | Done when |
|---|---|
Remove noindex and staging blocks from production | View-source on the live landing page shows no noindex; robots.txt allows public pages |
| Title and meta description on every launch page | Unique per page; checked with a meta tag generator |
| Open Graph image and tags | Image is at least 1200 × 630 px; preview renders in a link debugger |
| Sitemap updated and submitted | New URLs are in the sitemap and it's submitted in Search Console |
| Analytics events firing | Signup and activation events show in your analytics dashboard from a test account |
| Error monitoring and alerting | A test exception reaches the on-call person's phone |
| Billing tested end to end | A real card completes checkout, upgrade, downgrade and cancel |
| Landing page speed checked | LCP, INP and CLS are in the "good" range on a mobile test |
| FAQ structured data (optional) | Markup matches the visible FAQ; built with an FAQ schema generator |
| Favicon and app icons | Icon shows in browser tabs and bookmarks; made with a favicon generator |
| Status page or status channel | A public URL where you'll post if something breaks on launch day |
Two of these trip teams up often. First, robots.txt won't hide a staging site: Google's robots.txt guide says it "is not a mechanism for keeping a web page out of Google" and recommends noindex or password protection instead. The flip side is that a noindex copied from staging to production will quietly keep your launch page out of search.
Second, social previews. Meta's image guidelines for link shares recommend images of at least 1200 × 630 pixels at roughly a 1.91:1 ratio. Our OG image generator outputs that size. For the sitemap, Google's sitemap documentation calls submission "merely a hint", so submit it, but don't expect it to force indexing on launch day. The sitemap XML generator and robots.txt generator help if you don't have these files yet.
For page speed, web.dev's Web Vitals article sets the "good" thresholds: LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of page loads. A launch page with a heavy hero video often fails LCP on mobile, so test on a throttled phone profile, not just your laptop. (Landing-page design itself is covered in our product launch website guide.)
Changelog format
The changelog you started in phase 1 is linked from the launch post and every follow-up release, so settle its format now. Keep a Changelog is a published convention for this. Its principles include "Changelogs are for humans, not machines," an entry for every version, the latest version first, and a release date on each one. It groups changes as Added, Changed, Deprecated, Removed, Fixed and Security. Adopt it, or something like it, and your week-2 follow-up release is a matter of filling in a section.
Phase 3: Freeze and rehearse (T−7 to T−1 days)
The last week is for removing risk, not adding features.
| Task | Done when |
|---|---|
| Feature freeze | Only launch-blocking bug fixes merge after this date |
| Load test signup, demo and API | The paths a launch spike hits handle several times normal traffic without errors |
| Fresh-eyes onboarding test | Someone who has never seen the product signs up while you watch silently |
| Schedule the Product Hunt post (if used) | Scheduled for 12:01 AM Pacific; maker comment saved |
| Brief helpers | Everyone replying on launch day knows the time, links and tone |
| Prepare a rollback plan | You know how to revert the last deploy in under ten minutes |
| Send the T−1 email to early users | They know when and where the launch goes live |
Which load test to run
"Load test" covers several different tests. Grafana's guide to load testing types (written for its open-source k6 tool, but the terms are general) separates them. For a launch, three matter:
| Test | Grafana's definition | Launch use |
|---|---|---|
| Smoke test | Verifies "the system functions with minimal load" and gathers baseline values | Run first, on every launch-critical path, to confirm the test script itself works |
| Average-load test | Assesses performance "under a typical load" | Your normal traffic, as the baseline to compare against |
| Spike test | Verifies the system "survives and performs under sudden and massive rushes of utilization" | The closest model of a front-page moment: signup, demo and docs under a sudden jump |
Our advice: spike-test the paths a visitor hits in their first five minutes (landing page, signup, email confirmation, the demo, the quickstart's first API call) and leave the rest of the app alone. Note the point where errors start, and decide in advance what you'll switch off (a heavy dashboard widget, a live preview) if traffic reaches it.
On timing: Product Hunt's launch guide says the day runs on Pacific time, recommends scheduling for 12:01 AM PT, lets you schedule up to a month ahead, and asks makers to request feedback rather than upvotes.
Phase 4: Launch day
Launch day has few tasks, but they all happen fast. Keep this list on a second screen.
- Hour 0: Publish the launch post. Post on the primary channel. Add the first comment immediately.
- Hour 0–1: Send the waitlist email. Post the social thread. Tell early users the link is live.
- All day: Reply to every comment, ideally within the hour. Critical replies matter most, because quiet readers judge you by them.
- All day: Watch error rates and signup completion. Ship small fixes and mention them in the thread.
- End of day: Note every bug, feature request and objection in one document. Thank the people who helped.
Don't post to every community at once. Space secondary channels across days one to three so you can give each thread full attention. Channel-specific rules are in our Product Hunt launch guide and, for running the day as a live event, the virtual product launch guide.
Launch-day roles
Even a two-person team should split the day into roles, written down the day before:
| Role | Owns | Doesn't touch |
|---|---|---|
| Responder | Every comment thread, the inbox, social replies | Production deploys |
| On-call | Error alerts, signup funnel, hotfixes, the status page | Public threads, except to confirm a fix shipped |
| Lead (often the responder) | The go/no-go call, rollback decisions, the end-of-day notes | Nothing; this person can override either role |
Incident rule and message template
Set the rollback threshold before launch so nobody debates it under pressure. One workable rule (ours, adjust it): if signup completion drops below half its rehearsal rate for 15 minutes, roll back first and investigate after. When something breaks, post one short message on the status page and in each active thread:
- What's broken: "Signup emails are delayed by about ten minutes."
- Who's affected: "New accounts only; existing users aren't affected."
- What you're doing: "We've rolled back the last deploy and are watching the queue."
- When you'll update: "Next update in 30 minutes, or sooner when it's fixed."
Then keep that promise. A thread that sees a clear incident update followed by a fix usually trusts you more than one that saw no problems at all.
Phase 5: Post-launch (week 1 to week 4)
Most launch checklists stop at launch day. That's where the product launch steps that actually create users begin.
| When | Task | Done when |
|---|---|---|
| Day 1–3 | Publish a short product launch post-mortem or "what we learned" update | Live on the blog and shared to the same channels |
| Week 1 | Triage all launch feedback into the backlog | Every item is tagged fix, build, decline or investigate |
| Week 1 | List the product on discovery platforms | Listing is live on TechLogHub via submit and other relevant directories |
| Week 2 | Ship one visible fix requested at launch | Changelog entry plus a post on the releases feed |
| Week 2 | Email signups who didn't activate | One plain-text email asking what blocked them |
| Week 4 | Review launch metrics | Activation rate, week-1 and week-4 retention, and best channel recorded |
The week-2 follow-up release is the most skipped item on this list and one of the most valuable. It gives launch visitors a reason to come back and shows them the product is maintained.
The week-2 email to inactive signups
Keep it plain text, from a person, and short enough to answer from a phone. A template:
- Subject: Quick question about [product]
- Line 1: "You signed up for [product] last week but haven't [activation event] yet."
- Line 2: "Was something in the way? A one-line reply is plenty. I read every one."
- Line 3 (optional): a single link to the quickstart, or to the fix you shipped for the most common launch-day complaint.
Tag each reply with the blocker it names (setup, pricing, missing feature, unclear value) and feed the counts into the week-4 review.
Worked example: a two-person launch plan
Here's a hypothetical plan to show how the phases fit on a real calendar. Two founders, Asha (product and engineering) and Dev (docs, content and community), are launching a self-hosted log viewer. They chose Show HN as primary, with a self-hosting subreddit and their own email list as secondary. Launch day is a Tuesday.
| Week | Asha | Dev |
|---|---|---|
| T−8 | Activation event defined and tracked (first log source connected) | Pitch written and tested on three outsiders; channel rules read |
| T−7 | Public demo instance with seeded logs, no signup | Waitlist form, sending domain authenticated, privacy policy |
| T−6 to T−5 | Early-access build to 15 users | Changelog live; early-user feedback collected weekly |
| T−4 to T−3 | Billing, analytics, error monitoring, meta and OG tags | Launch post, quickstart timed at under five minutes, screenshots |
| T−2 | Spike test on signup, demo and quickstart | First comments drafted for each channel; FAQ on landing page |
| T−1 | Feature freeze, rollback rehearsal, noindex check | T−1 email to waitlist and early users; roles agreed |
| Day 0 | On-call | Responder |
| Week 1–2 | Fix the top launch bug; tag the release | Post-mortem; listing on submit; inactive-signup email |
| Week 4 | Pull the metrics | Write the review and share it with early users |
Notice what the example cuts. There's no press list (tier 1, but a niche product), no Product Hunt (the product has little visual UI), and no paid promotion. Cutting rows is part of the checklist, not a failure to complete it.
Week-4 launch review template
Four weeks after launch, write a one-page review. Use the same headings each time so launches can be compared:
| Section | What to record |
|---|---|
| Numbers | Signups, activation rate, week-1 and week-4 retention for the launch cohort, using the definitions you set in phase 1 |
| Channels | Signups and activated users per channel, and activation rate per channel |
| Feedback | Top five requests and top five blockers, with counts from the triage tags |
| What broke | Every incident, how long it lasted, and what would have caught it earlier |
| Checklist changes | Rows to add, rows to cut, and estimates that were wrong |
| Next release | The tier 2 release this launch's feedback points to, with a date |
The "checklist changes" section is how this page becomes your team's own. Copy it forward and edit it after every launch. A diff between two versions of the plan, made with a text diff checker, shows exactly what you learned.
Common checklist failures
| Failure | How to catch it |
|---|---|
| Tasks without owners | No ticket can be created without a single owner |
A staging noindex shipped to production | View-source on launch morning, as a T−0 ticket |
| Demo gated behind signup when the primary channel requires something people can try | Decide channels in phase 1, so the demo is an engineering task from week −8 |
| Launch emails landing in spam | Authenticate the sending domain in phase 1 and send test emails to Gmail and Outlook addresses |
| No rollback plan | Rehearse a rollback during freeze week and time it |
| Stopping at day zero | Put post-launch tickets on the board before launch, with dates |
FAQ
What should a product launch checklist include?
It should cover five phases: foundations (positioning, waitlist, activation metric), assets and technical readiness (launch post, docs, meta tags, OG images, analytics, billing), a pre-launch freeze, launch-day tasks and post-launch follow-up. Each task needs an owner and a clear done-when test.
How far in advance should I start launch planning?
About eight weeks for a new product. Positioning, early users and a no-signup demo take the longest. A feature release can compress the plan to two or three weeks, and a minor update needs only a changelog entry.
What are the technical steps to launch a new product website?
Remove any noindex left from staging, give every page a unique title and meta description, add Open Graph tags with a 1200 × 630 image, update and submit the sitemap, confirm analytics and error monitoring work, and test billing end to end.
What time should I launch on Product Hunt?
Product Hunt's day runs on Pacific time, and its launch guide recommends scheduling for 12:01 AM PT. You can schedule up to a month in advance.
Does a small waitlist need SPF, DKIM and DMARC?
Google's sender guidelines require SPF or DKIM for all senders to personal Gmail accounts, and SPF, DKIM and DMARC for senders of more than 5,000 messages a day. A small list is below that bulk threshold, but setting up all three records is cheap and protects the one email you most need delivered on launch day.
What should I do after launch day?
Publish a short post-mortem, triage all feedback, list the product on discovery platforms, ship one visible fix within two weeks, email signups who didn't activate, and review activation and retention after four weeks.
Every row gets an owner, every owner gets a done-when test, and the checklist ends four weeks after launch, not on launch day.