# The launch often goes wrong the week before > Why strong launches usually look boring up close: channel fit, frozen scope, a written schedule, and a content runway that starts before anyone posts. - Canonical HTML: https://growth.iangoh.com/blog/the-launch-often-goes-wrong-the-week-before/ - Published: 2026-05-24 - Updated: 2026-05-24 - Categories: launches, SEO, operator systems - Niches: SaaS, developer tools, AI products, creator tools ## On this page - The audience should fit the feature, not the calendar - Launch week is a bad time for fresh technical risk - A written day is easier to survive than a heroic day - Content quality is usually decided before the writing week - What this means for smaller teams ## Start with these related tactics - [Feature-specific launch channel map](/growth-ideas/feature-specific-launch-channel-map/): Match each launch to the channels that naturally care about that feature instead of reusing the same promotion plan every time. - [One-week prelaunch prod freeze](/growth-ideas/one-week-prelaunch-prod-freeze/): Finish the risky integrations and production shipping about a week before launch so launch week is for publishing, support, and fixes, not hero debugging. - [Launch-day minute-by-minute run sheet](/growth-ideas/launch-day-minute-by-minute-run-sheet/): Write the launch day down to the minute so publishing, social, community, and support happen in sequence without decisions being remade under stress. A lot of launch advice makes the day itself sound like the whole game. Pick the headline. Rally the people. Hit publish. I think that framing hides where most launches actually go bad. They usually go bad earlier, when the team is still pretending that one audience fits every feature, that production can keep changing until the last minute, and that content will somehow become sharp under deadline. ## The audience should fit the feature, not the calendar Supabase is useful here because it treats launch distribution as part of the product story. The team did not push every announcement through the same channels. A design-oriented release wanted front-end and design circles. A more technical storage release wanted developers and places like Hacker News. That is the logic behind a [feature-specific launch channel map](/growth-ideas/feature-specific-launch-channel-map/). This sounds obvious, but teams ignore it all the time. They build one launch ritual and then drag every feature through it, even when the people who care most are somewhere else. ## Launch week is a bad time for fresh technical risk The calmer move is a [one-week prelaunch prod freeze](/growth-ideas/one-week-prelaunch-prod-freeze/). Supabase learned to stop shipping major integrations on the day of launch and instead used the week before for testing, edits, and swarming on blockers. That is not bureaucracy. It is respect for the fact that traffic, support, bug reports, and public conversation all arrive at once. If the product is still changing under your feet, the launch starts by spending trust. ## A written day is easier to survive than a heroic day Supabase also described a [launch-day minute-by-minute run sheet](/growth-ideas/launch-day-minute-by-minute-run-sheet/) with exact timestamps for Product Hunt, blog publication, tweets, and live community moments. That kind of schedule can look excessive from far away. Up close it is just merciful. The written sequence removes dozens of tiny choices at the exact moment the team can least afford to keep re-making them. ## Content quality is usually decided before the writing week Buffer made the same point from a different angle. Its blog growth did not come from panic-publishing. It came from an [editorial four-to-six-week runway](/growth-ideas/editorial-four-to-six-week-runway/) that gave each post time to be researched, edited, and promoted properly. Then the company gave those posts a first-day audience through an [owned newsletter seed for new posts](/growth-ideas/owned-newsletter-seed-for-new-posts/). Search still mattered, but the post did not have to begin life alone. ## What this means for smaller teams For SaaS and AI products, the point is not to copy Supabase's scale. It is to steal the discipline. Pick the audience that fits the feature. Freeze the risky work before launch. Write the day down. Give your essay or launch post enough runway that it can become readable instead of merely finished. The trap is treating calm systems as overhead. Usually they are the thing that lets the launch look energetic in public without feeling chaotic in private. ## Related GrowthDex tactics - [Feature-specific launch channel map](/growth-ideas/feature-specific-launch-channel-map/) - Product Hunt, Hacker News, Communities, Launches - [One-week prelaunch prod freeze](/growth-ideas/one-week-prelaunch-prod-freeze/) - Website, Launches, QA - [Launch-day minute-by-minute run sheet](/growth-ideas/launch-day-minute-by-minute-run-sheet/) - Product Hunt, X/Twitter, Content, Launches - [Editorial four-to-six-week runway](/growth-ideas/editorial-four-to-six-week-runway/) - SEO, Content, Editorial - [Owned newsletter seed for new posts](/growth-ideas/owned-newsletter-seed-for-new-posts/) - Email, SEO, Content ## Essay chronology - [Newer essay: The launch keeps going after launch day](/blog/the-launch-keeps-going-after-launch-day/) - launch strategy, brand trust - [Older essay: The machine reader is part of the audience now](/blog/the-machine-reader-is-part-of-the-audience-now/) - SEO, AI discovery, content systems ## Keep reading - [The Product Hunt page should keep working after launch day](/blog/the-product-hunt-page-should-keep-working-after-launch-day/) - Product Hunt, launches, SEO - [The launch page should explain itself before the room tries to help](/blog/the-launch-page-should-explain-itself-before-the-room-tries-to-help/) - launches, brand trust, SEO - [The launch only works if the next surface keeps working](/blog/the-launch-only-works-if-the-next-surface-keeps-working/) - launches, community-led growth, SEO ## Continue through the blog - [SaaS](/blog/#path-saas) - 3 essays in this path - [AI products](/blog/#path-ai-products) - 3 essays in this path - [developer tools](/blog/#path-developer-tools) - 3 essays in this path ## Sources - [Product Hunt Stories](https://www.producthunt.com/stories/how-we-launch-at-supabase) · [GrowthDex source hub](/sources/product-hunt-stories-producthunt-com/) - [Buffer Blog](https://buffer.com/resources/buffer-blog-one-million/) · [GrowthDex source hub](/sources/buffer-blog-buffer-com/) ## Editing notes - Kept the argument narrow: launches usually fail before the launch day itself. - Removed startup pageantry language and used plain nouns like schedule, freeze, audience, and runway. - Avoided listicle structure by letting the essay move as an argument instead of a checklist. - Used short paragraphs and a few direct judgments so it reads like an operator essay, not a marketing post. ## Advisory If you want help turning this into a growth system, Ian Goh offers advisory at https://iangoh.com/advisory.