AIWorkDex
Marketing Practice

Build a Launch HN or Show HN package

Prepare a factual submission, inspectable product route, response plan, and result record for Launch HN or Show HN.

Preparation
One preparation session, launch day coverage, and one review.
Difficulty
Moderate
Task
Prepare an HN product launch
Back to the Task: Prepare an HN product launch

Before you start

Get what you need before you start

  • Confirm that Launch HN or Show HN fits the product and intended audience.
  • Confirm that the product or demo, pricing information, and promised access are ready.
  • Assign people for technical incidents, product questions, moderation, and claim approval.
  • Use Google Sheets only as the launch record; the Practice has no supported universal launch Tool.

Steps

Work through the method

Use the listed inputs and tools. Check the evidence when you need to verify a step.

  1. Extract the current HN guidance

    Confirm route eligibility first. Use Launch HN only for its curated YC route and Show HN for work people can try under the separate Show HN guidelines. Record access, pricing, title, tone, story, disclosure, moderation, and response requirements with locators and a check date.

    Why it matters: The submission must follow the current HN guidance for this channel.

    Input
    The official HN guidance, product state, launch date, and intended audience.
    Output
    A dated channel checklist with source locators, owners, and any unresolved rule question.
    Tools in this stepGoogle Sheets

    Evidence for this step

  2. Assemble the story and proof

    Draft a factual title and personal account of what the product does, who it serves, why it exists, what is available now, pricing, limitations, and how the community can inspect it.

    Why it matters: A specific, inspectable account gives the community something it can evaluate and question.

    Input
    The product, demo, approved positioning, product facts, founder context, pricing, and known limits.
    Output
    A draft submission with claim evidence, product access, pricing, limitations, and disclosure notes.
    Tools in this stepGoogle Sheets

    Evidence for this step

  3. Rehearse the response path

    Test the product route with a fresh account or browser. Prepare factual answers for likely questions and escalation routes for outages, abuse, security, billing, and claims.

    Why it matters: The launch promise includes access and timely response, which a polished post alone cannot provide.

    Input
    The draft submission, launch build, test accounts, incident contacts, and support boundaries.
    Output
    A passed readiness record, response rota, escalation contacts, and decision to launch, revise, or postpone.
    Tools in this stepGoogle Sheets

    Evidence for this step

  4. Record what happened

    Capture questions, access failures, moderation events, product feedback, and separate attention, use, retention, and revenue signals. Decide what to fix without treating launch attention as durable demand.

    Why it matters: One launch event can reveal practical problems while remaining weak evidence for long-term adoption.

    Input
    The live submission, response log, incident record, product data, and original launch objective.
    Output
    A launch review with observations, limits, owners, and the next product or marketing action.
    Tools in this stepGoogle Sheets

    Evidence for this step

Success checks

Check the result before you finish

  • Every checklist item links to the current Launch HN or Show HN guidance.
  • The product or demo, access, pricing, limitations, and claims were tested before submission.
  • Named responders and escalation routes covered the launch window.
  • The review separates attention, questions, use, retention, and revenue.

Failure modes

Watch for these problems

  • The copy reads like a generic advertisement. Rewrite it around the product, context, and inspectable facts.
  • The promised product route fails. Postpone or correct the launch before inviting more people.
  • A material relationship is hidden. Add the required clear disclosure before publication.
  • The team treats launch-day traffic as durable adoption. Return to later use and retention evidence.

Tools

Choose the tools you need

Sources

Read the sources behind this practice

Check what each source supports and where the advice has limits.