Launch

Launch is not an event; it's a switch you flip after the work is done, and for almost everyone it's quiet. The mistake is treating one day as the moment that decides everything, pouring months of hope into 24 hours, then going silent when the internet shrugs. Launch is a starting line, not a finish line.

The concept

A launch is making your product publicly available and telling people. Two truths sit in tension:

1. Launch matters, it's a real milestone, a coordination point, a reason for people to pay attention on a specific day.
2. Launch matters less than you think, the vast majority of successful products had a quiet launch and grew afterward through sustained distribution (Parts IX-X). A big launch spike that isn't backed by retention (Chapter 50) evaporates.

Hold both. Plan a real launch; don't stake the company on its first day.

📐 Building is not shipping, and a submittable product is not a launched one. The last 10%, payments tested on a real transaction, the flow proven on real hardware, analytics wired, legal matched, is unglamorous and it is the whole game. Everything that matters after launch can only be learned by launching.

You can launch more than once

"Launch" feels singular and final. It isn't. You can, and should, launch repeatedly:

 SOFT LAUNCH     to your list and a small group; catch the embarrassing bugs
 PLATFORM LAUNCH Product Hunt, Show HN, relevant subreddits, App Store
 MILESTONE LAUNCH each big feature, each integration, each milestone is a new reason to reach out
 GEO / SEGMENT   new market, new audience — a fresh launch to a fresh crowd

Each is a fresh reason to contact your audience and the press. The founders who "launch once" leave most of the distribution on the table.

Launch to your warmest audience first

Sequence by warmth. The order that works:

 1. YOUR LIST         the waitlist and early believers — warmest, highest intent (Chapter 44)
 2. YOUR COMMUNITY    wherever you've been contributing (Chapter 47)
 3. PLATFORMS         Product Hunt, Hacker News, subreddits — colder, wider
 4. PRESS / CREATORS  if you have relationships; cold outreach rarely converts

Your list converts best because they already asked to hear from you. Platforms are colder and wider. Don't lead with the coldest channel.

Launch readiness: the switch only flips once things are real

Before you flip the switch, the unglamorous gates must be green:

• The core flow works on real hardware / real accounts, not just your dev machine (Chapter 31).
• Payments work end to end, with a real transaction tested (Chapters 26, 27).
• Analytics fire so you can actually see what launch traffic does (Chapter 38).
• Legal is in place, privacy policy, terms, store requirements (Chapters 36, 40).
• Support can receive a message (Chapter 42).
• Someone is available on launch day to answer and fix.

A launch that sends traffic to a broken funnel is worse than no launch, you spend attention you can't get back.

The one-rejection / one-shot budget

Some launches you don't fully control. App-store review can reject you days before your date. A Product Hunt launch is effectively once per product for the big spike. Plan for the gate you don't control: submit early, leave buffer, and don't attach an irreversible marketing date to an approval you haven't received (Chapters 33, 37).

After the switch: the part that matters

Launch day generates a spike; what you do next determines whether it mattered:

• Respond to everything, every comment, question, and piece of feedback, fast. Launch-day engagement is disproportionately valuable.
• Watch the funnel live, where do people drop? Launch traffic is your first real usage data (Chapter 49).
• Fix fast, the bugs real users hit in the first hours are your priority list.
• Capture the momentum, convert visitors to signups, signups to a list, so the spike leaves a residue you keep.

📐 Best practice

Plan a real launch, but don't stake everything on one day.

Launch to your warmest audience first, coldest last.

Launch more than once, soft, platform, milestone, segment.

Green the readiness gates, real-hardware flow, payments, analytics, legal, support.

Submit early where a reviewer controls your date; keep buffer.

Be present on launch day to respond and fix.

Watch the funnel live and fix the first real bugs fast.

Capture the spike into a list you keep.

Have a plan for the day after, launch is the start of distribution, not the end.

Treat the launch as a distribution habit, not a one-time event.

💀 Common mistakes

Staking everything on launch day, then going silent when it's quiet.

Launching to the coldest channel first and burning the one-shot spike on strangers.

Launching into a broken funnel, traffic hits a bug, a dead payment, an untracked page.

Attaching an irreversible date to an approval you don't control (Chapters 33, 37).

No analytics at launch, the one moment of real traffic, unmeasured.

Disappearing on launch day instead of responding to everything.

Treating launch as a finish line, no plan for the day after.

One giant launch and never again, leaving repeat launches unused.

A vanity spike with no retention behind it, traffic that evaporates.

Launching before the product is actually ready, to hit a self-imposed date.

The professional workflow

 1. READINESS GATES GREEN
    real-hardware flow · payments · analytics · legal · support · someone on call

 2. SOFT LAUNCH to your list + a small group; fix what breaks

 3. PREP ASSETS
    landing page · demo · screenshots/video · launch copy · FAQ

 4. SEQUENCE BY WARMTH
    list → community → platforms → press/creators

 5. SUBMIT EARLY where a reviewer gates the date; keep buffer

 6. LAUNCH DAY
    post · respond to everything · watch the funnel · fix fast

 7. CAPTURE the spike into a list you own

 8. DAY AFTER — analyse funnel, prioritise fixes, plan the next launch

 9. RE-LAUNCH on milestones, features, and new segments

Tools, websites & costs

A launch costs almost nothing but attention and preparation. The store fees are the only hard cost, and you've already paid them (Chapter 33).

Alternatives & trade-offs

Big-bang vs rolling launch. A big-bang concentrates attention on one day (good for platforms that reward a spike) but is fragile and one-shot. A rolling launch (soft → segments → milestones) is steadier, lower-risk, and compounds. Most products benefit from rolling, with one deliberate big-bang on the channel that rewards it.

Launch early vs launch polished. Launching early gets real feedback sooner and risks a weak first impression; launching polished protects the impression and delays learning. Bias early for a soft launch to a forgiving audience; be more polished for a public one-shot spike.

Product Hunt vs Hacker News vs Reddit vs stores. Each rewards different things, PH rewards a coordinated push and a clear product; HN rewards technical substance and hates marketing; Reddit rewards genuine community membership and punishes drive-by promotion; stores reward ongoing optimisation. Match the channel to your product and your credibility there. Don't spam all four the same day with the same copy.

Launch with press vs without. Press can amplify but rarely covers unknown early products, and chasing it costs time better spent on channels you control. Skip cold press early; earn it later with traction.

Checklist

• Readiness gates green: real-hardware flow, payments, analytics, legal, support
• Someone is available on launch day
• I've done a soft launch to my list and fixed what broke
• Launch assets are ready (page, demo, screenshots, copy, FAQ)
• I launch warmest-first (list → community → platforms)
• I submitted early where a reviewer gates my date
• Analytics will let me watch the funnel live
• I have a day-after plan (funnel analysis, fixes, next launch)
• I can capture the spike into a list I own
• I've planned repeat launches for milestones and segments

📓 Case Study: the launch that never happened, and the gates that explain why

Project: SOLIS. The most honest case study in the handbook, because the product never launched. It was built to a submittable state, an iOS app that could have gone to App Store review, and the switch was never flipped. That absence is the lesson.

⚠️ The primary deviation: months of building, zero public launch. SOLIS is a complete, polished, submittable product with no users and no revenue. Every downstream chapter that depends on real usage, retention (50), metrics (49), support (42), growth loops (51), has nothing to measure because the launch that would have generated the data never occurred. A product that doesn't launch cannot teach you the only things that matter after launch. The single biggest lesson SOLIS offers is a negative one: building is not shipping, and a submittable product is not a launched one.

Why it stalled is instructive: the readiness gates weren't all green, and some were never proven. Late in the project, an honest inventory of what had not been validated on real hardware existed:

• The in-app purchase flow was built but never tested against a real StoreKit transaction, payments, the gate this chapter calls non-negotiable, was unproven (Chapter 26).
• The core flow had not been exercised on a physical device through a full session, only in the browser preview and simulator (Chapter 31).
• Analytics to watch launch traffic were not wired (Chapter 38), a launch would have been flown blind.
• The privacy policy and label did not yet match the product's real data collection (Chapter 40).
• The waitlist endpoint was still an open relay (Chapter 44).

Any one of these is a reason not to flip the switch. Together they explain the stall: the unglamorous launch gates were the actual remaining work, and they were consistently deferred in favour of more building, more lessons, more art, more polish on surfaces that were already good.

⚠️ A self-imposed launch date with no reviewer buffer. The project carried a goal of App Store live within roughly two weeks while the payment flow, device testing, analytics, and legal items were all still open. That's the exact trap of Chapters 33 and 37: attaching a date to an approval you don't control, on top of gates you haven't greened. The date was aspirational; the gates were real; the gates won.

🚩 Everything this chapter teaches about launch day is untested here. Warmest-first sequencing, responding to everything, watching the funnel live, capturing the spike, re-launching on milestones, none of it happened, because day zero never came. The plan for launch existed on paper; the execution is entirely hypothetical.

What generalises from a launch that didn't happen:

1. The gap between "submittable" and "launched" is where products die. The last 10%, payments tested on real transactions, the flow proven on real hardware, analytics wired, legal matched, is unglamorous, and it's the whole game.
2. Building is the fun part and the trap. Every hour on a new lesson or a nicer animation was an hour not spent greening a launch gate. The pull toward building over shipping is real and it has to be resisted deliberately.
3. A launch date is only meaningful if the gates it depends on are tracked and closable. A date over open, uncontrolled gates is a wish.

Lessons

1. Building is not shipping. A submittable product is not a launched one, and only launching teaches you what matters after launch.
2. Launch is a starting line, not a finish line. Plan the day after before the day itself.
3. Launch warmest-first, list, then community, then platforms, then press.
4. The readiness gates are the real work. Payments tested on a real transaction, the flow proven on real hardware, analytics wired, legal matched, non-negotiable.
5. The last 10% is where products die. It's unglamorous, and building is more fun, resist the pull.
6. Don't attach an irreversible date to gates you haven't greened or approvals you don't control.
7. Be present on launch day, respond to everything, watch the funnel, fix fast.
8. Capture the spike into a list you keep; a spike without retention evaporates.
9. Launch more than once, soft, platform, milestone, segment.

Next: Chapter 46: Content Marketing and SEO →