How to use the launch checklist
A launch checklist is useful when it protects the product from preventable mistakes, not when it creates ceremony. Start by deciding what this release actually is: the first public version, a substantial update, or a relaunch after meaningful work. Write down one audience, one problem, and one outcome a visitor can verify. That sentence should guide the listing title, screenshots, demo, and replies. If a destination has its own eligibility rules, read them before choosing a date. A rejected listing is usually harder to recover than a delayed one.
Test the public path as a stranger would. Use a private browser window, a narrow screen, and an address that has never signed in. Complete the main action, then deliberately trigger validation, empty, loading, and failure states. Check that pricing, trial limits, privacy terms, and support details match what the product really does today. Remove old claims from screenshots and metadata. If the launch depends on a waitlist, invitation, platform, country, or paid plan, say so before people click. Clear constraints earn more trust than a broad promise that breaks on first use.
Prepare a small evidence pack instead of rewriting facts for every site. Keep the canonical product URL, stable product name, specific tagline, original description, maker identity, category, launch date, screenshots, social card, and any eligibility evidence together. Describe observable capabilities and intended users; avoid invented customer counts, unsupported comparisons, or vague superlatives. A short demo should show the actual workflow with realistic data. Preview the page title and social image at their rendered sizes. Check every source link and make sure the person answering questions can explain how each claim was established.
Treat launch day as support work. Confirm each destination’s timezone and whether a scheduled post can still be edited. Keep uptime and error monitoring visible, and reserve time to answer questions without copying a sales script. Disclose that you made the product. Do not buy, trade, automate, or pressure people for votes, comments, or reviews. Ask a small group to try the product and give honest feedback instead. If something fails, update the listing with the limitation and a realistic repair note. A calm, accurate response is more valuable than defending a rank.
After the board closes, save the permanent launch URLs and record results in one timezone. Separate visits from meaningful actions such as completing onboarding, creating a project, or paying. Keep feedback in three buckets: defects to fix, questions that reveal unclear copy, and ideas that need more evidence. Correct broken facts on directory listings and publish a short post-mortem while decisions are fresh. The checklist stays in this browser only; export or print it if you need a durable team record. Reuse the structure for a future release, but recheck destination rules and costs because they can change.
Primary rules checked
These sources are starting points, not substitutes for checking each destination again on launch day.
Checklist reviewed . Found a broken rule? Send a correction.
For the reasoning behind the board, read why we built ZeroRaised, then submit an eligible bootstrapped product when the launch is ready.