You came for a product launch checklist — the phases, the items, something to paste into a doc before you ship. It's below; take it. But know what you're getting: a checklist is a list of checkboxes, and a checkbox only records that something was true once. The instant an upstream decision moves — you re-price, you re-cut the spec, GTM shifts a week — the items that depended on it are quietly wrong, but they're still green, because nothing in a Notion table or a Google Doc connects "pricing decided" to "pricing page shipped." Draftlize gives you the same checklist — and makes each item a card wired to what it depends on, so the relevant items flag themselves stale the moment something upstream changes.
This is the whole launch plan checklist — Pre-launch, Launch day, Post-launch. It works in a doc, a wiki, or a project board; use it as-is. The next section is about what changes when each item stops being a checkbox and becomes a card that knows what it depends on.
The build scope is locked and written down. Every item below assumes this spec — which is exactly why re-cutting it after the fact silently invalidates half the list.
The people who own the outcome have agreed on what ships and what doesn't. Not a Slack thumbs-up — a recorded decision you can point back to.
Plan, price, and packaging are final. The single most upstream decision on the page: pricing page, billing, paywall copy, and the GTM narrative all hang off it.
Checkout works end to end, the paywall enforces the plan you decided, and a real card gets charged in a test. Downstream of pricing — so it goes stale the instant pricing moves.
Positioning, launch copy, and the channels (site, email, social, any press) are drafted and scheduled. All of it assumes the price and the feature set hold.
The critical paths are tested on production-like data, the regressions are clear, and the known-issues list is honest about what ships broken.
The events that tell you whether launch worked are firing and verified before launch, not bolted on after — you can't measure a launch you didn't instrument.
A tested way to undo the deploy, and a written line for who calls it and when. The cheapest item to skip and the most expensive to be missing at 2am.
Ship to production behind whatever gate you planned — flag, gradual rollout, or full cutover — and confirm the build that went out is the one you signed off.
Run the critical paths against live production once it's out: sign up, pay, do the core action. The five minutes that catch the config that was only wrong in prod.
Flip the site, send the email, post the threads — in the order you planned, only after the smoke test is green. Announcing a broken build is the one mistake you can't un-send.
Watch errors, latency, signups, and payments live for the first hours. Someone is explicitly on call and watching the dashboards, not assuming green.
Read the launch against the numbers you instrumented — activation, conversion, the one metric you said would define success. Compare to what the PRD predicted.
Pull the first wave of user reactions, support tickets, and confusion into one place where it can turn into decisions, not vanish into Slack.
What the checklist missed, what went stale that nobody caught, what to change before the next launch. The item that makes the next launch cheaper.
Turn what you learned into updated decisions and specs — so the next launch starts from current truth, not from a doc that froze on launch day.
That's the checklist. Below: why ticking a box is the moment it starts to lie — and what we do about it.
Ticking "pricing decided" is true at the moment you tick it and never re-checked after. A checklist in Notion or a Google Doc captures a state once; it has no idea when the thing it recorded stopped being true, because a list of checkboxes can't watch the rest of the launch change.
You re-price three days before launch. Now the pricing page, the billing wiring, the paywall copy, and the GTM narrative are all wrong — but every one of those items is still green, because nothing connects "pricing decided" to the four items downstream of it. The checklist that was supposed to protect the launch is the thing that hides the breakage.
A fully-ticked launch checklist feels like readiness, which is exactly why it's risky: you can't tell which of the green items went stale after you ticked them. The whole list reads as done while a real fraction of it is fiction — and you find out which fraction during the launch, not before.
In Draftlize the launch checklist isn't a list of ticks — each item is a typed card: the decision or spec it represents, who owns it, what state it's in, and what it depends on. Structured, addressable by ID, and citable from the PRD or a thread instead of buried in a doc.
Because each item's dependencies are real links and not implied, re-pricing turns every card that rested on the old price — pricing page, billing, paywall, GTM — stale automatically, the way a build system invalidates everything downstream of a changed file. The green you can't trust by hand, the substrate keeps honest.
Claude Code or Cursor, over MCP, reads every relevant decision and spec before it drafts the launch copy or the release notes, and writes status back into the same cards. The checklist stops being a doc someone forgets to update and becomes context the agent re-reads on every turn.
A checklist tells you what to do before launch. It can't tell you when something you already ticked stopped being true.Keep the three phases. Let the substrate keep them honest.
A product launch checklist is the list of everything that has to be true before, during, and after a launch — across product, marketing, sales, support, and legal — so nothing critical is missed under deadline pressure. It turns a chaotic launch week into a set of owned, verifiable items.
Three phases. Pre-launch: final QA, docs, pricing and billing, marketing assets, support enablement, legal sign-off. Launch: deploy, announce, monitor. Post-launch: gather feedback, watch metrics, fix fast. Each item needs an owner and a clear done state, or it becomes a tick nobody actually verified.
Pre-launch (build readiness and line everything up), launch (ship, announce, and watch), and post-launch (measure, learn, and iterate). Most launch pain comes from treating the checklist as pre-launch only and going quiet after ship day, when the metrics that decide success actually arrive.
A fully ticked list feels like readiness, but you cannot tell which green items went stale after you ticked them. Draftlize makes each item a card with real dependencies, so re-pricing turns every item that rested on the old price stale automatically — the green stays honest instead of hiding fiction until launch day.
Take the checklist above, or spin up a project and let the agent fill it in from your spec and PRD — then keep every item, and everything it depends on, current for you straight through launch day.
Start free with $5