Most launches that go wrong go wrong before the day: a sign-up that breaks on phones, a link that shares without an image, no way to tell which visitors came from where. This checklist runs over four weeks. Small products can do it in two.
It sits under our complete launch guide. When you get to the launch page itself, switch to writing a launch page.
Four weeks out: the product
Start with the thing people will actually touch.
- It works today. Launch something people can use, not a waitlist. Show HN's rules say "If your work isn't ready for users to try out, please don't do a Show HN", and most launch boards, including Every Debut, turn down waitlists and "coming soon" pages.
- Sign-up works for a stranger. Try it in a private window, on a phone, on a slow connection, with an e-mail address you have never used. Then try "sign in with Google" or GitHub if you offer them.
- The first five minutes make sense. After sign-up, does the person see something useful, or an empty screen? Add sample data or a short first step.
- Consider a no-account path. Show HN asks for work people can try "ideally without barriers such as signups or emails". A demo account, a sandbox or a free tool page lowers the bar for everyone else too.
- Pricing is visible. "Contact us" for a $9 tool reads as hiding something. If it is free during beta, say until when.
- Someone answers support. A contact address or form that a person reads during launch week.
- The basics are in place. A privacy policy if you collect personal data, and terms if people pay.
Done when: two people who have never seen the product reach the main feature on a phone without asking you anything.
Three weeks out: the site
Visitors judge the product by the first page. Fix the page they land on.
Speed
Google's "good" thresholds for Core Web Vitals are:
| Metric | Good |
|---|---|
| Largest Contentful Paint (loading) | within 2.5 seconds |
| Interaction to Next Paint (response) | 200 milliseconds or less |
| Cumulative Layout Shift (stability) | 0.1 or less |
They are measured at the 75th percentile of page loads, separately for mobile and desktop. If you are far off, the usual causes are huge hero images, too many third-party scripts and web fonts that block rendering.
Link previews
When someone shares your link, the preview comes from Open Graph tags. The protocol has four required properties: og:title, og:type, og:image and og:url. Add og:description (one or two sentences) and og:image:alt (what is in the image). Then paste your link into a chat app and look at it.
The rest of the first page
- The headline says what the product does in plain words. It should match the tagline you will use on launch platforms.
- HTTPS everywhere, no mixed-content warnings.
- A square logo and a favicon. Launch sites crop logos into squares.
- One clear call to action above the fold.
- The page loads without redirect chains. Every Debut's automated check, for example, wants an answer within 10 seconds and no more than five redirects.
Done when: your link shows a title and an image in a chat preview, and the page passes the speed thresholds on a phone.
Two weeks out: measurement
You will want to know, a week after launch, which source brought people who stayed. That needs a little setup now.
- Tag every link you share. Google Analytics says to always use three parameters:
utm_source,utm_mediumandutm_campaign. For example, a link you post on a launch board might carryutm_source=everydebut,utm_medium=launchandutm_campaign=nov-launch. Use a differentutm_sourcefor each place. - Pick one activation event. Not "signed up", but the first meaningful action: created a project, sent an invoice, published a page.
- Write down your normal numbers. Daily visitors, sign-ups and activations in an ordinary week. Dub described its #1 launch as 663 sign-ups, "an 8x increase from our daily average". You can only say that if you know the average.
- Prepare a simple sheet. Source, visits, sign-ups, activated, paying. Fill it daily during launch week.
Done when: a test visit with a tagged link shows up in your analytics under the right source.
Two weeks out: the people
A launch spreads through people who already care. Make the list now.
- People who asked to hear. Beta users, people who replied to a post, colleagues who said "tell me when it's ready". Ask permission if you are not sure.
- One honest message. What it is, who it is for, one link, and what you want from them: try it, and tell you what is confusing.
- E-mail rules. In the US, commercial e-mail falls under CAN-SPAM: accurate sender information, a subject line that matches the content, a valid physical postal address, a clear way to opt out, and opt-outs honoured within 10 business days. Other countries have their own rules, often stricter. Send from a tool that handles unsubscribes.
- No cold messages asking for votes. Peerlist's guidelines name "sending messages to Peerlist members whom you don't know and sharing launch links asking for upvotes" as spam. Other platforms treat it the same way.
Done when: you have a list of people who expect to hear from you, and a short message ready to send.
One week out: the launch page
Write the listing before you submit, in a document, and have two people read it. The details are in writing a launch page. Check that you have:
- A name and a tagline that says what the product does.
- A description: the problem, what the product does, who it is for, the price, and what is not done yet.
- A square logo and real screenshots, with alt text for each image.
- A first comment (Every Debut calls it the launch note): why you built it and what feedback you want.
If you launch on Every Debut, the listing limits are: name 2 to 40 characters, tagline 10 to 70, description 120 to 2,000, a logo and 1 to 6 gallery images, and a launch note of at least 10 characters.
Also prepare short, honest answers to the questions you will get:
- What does it cost, and will that change?
- What happens to my data?
- How is it different from the tool I use now?
- What is next on the roadmap?
- Who is behind it?
Done when: someone outside the project reads the listing and can tell you, in one sentence, what the product does.
The day before
- Run the sign-up test again on a phone.
- Check your hosting limits, e-mail sending limits and any rate limits on your API.
- Freeze risky deploys until the first 48 hours are over. Ship fixes, not features.
- Block your calendar for the first two days of the launch.
- Write your first reply to the most likely question, so you are not composing it at midnight.
One-page version
| Check | Done when |
|---|---|
| Usable today, not a waitlist | A stranger can use the main feature |
| Sign-up on mobile | Two new people get through without help |
| Pricing visible | Price or "free until" is on the site |
| Speed | LCP within 2.5 s, INP 200 ms or less, CLS 0.1 or less |
| Link previews | A shared link shows a title and image |
| Tagged links | Test visit appears under the right source |
| Activation event | One action defined and tracked |
| Baseline numbers | Normal daily figures written down |
| People to tell | A list and one honest message |
| Launch page | Tagline, description, images, first comment reviewed |
| Answers ready | Five likely questions answered in advance |
| Day before | Retested, limits checked, calendar blocked |
If you are launching on Every Debut
Every Debut runs automated checks on every submission: the site loads, uses HTTPS, is not parked, is not already listed, the listing is complete, and the product is not in a prohibited category. A person reviews it after that, and if we ask for changes or say no, you get a reason and can appeal once. Launching is free. You pick one of the next eight launch weeks, each running Monday to Monday in UTC. The rules are on how it works and the guidelines.
When the checklist is done, plan the week itself with the launch week plan, and look at where to launch if you have not chosen yet.