Lançamento — de soft launch ao Product Hunt
TL;DR
Lançamento não é um evento — é um processo de 3 fases: soft launch (50-100 pessoas, feedback e correção), community launch (comunidades de nicho, Indie Hackers, Reddit), e Product Hunt launch (alcance amplo, prova social). Cada fase tem objetivo diferente: soft corrige UX, community valida messaging, Product Hunt gera visibilidade. A preparação de 30 dias antes do Product Hunt é o que separa #1 Product of the Day de “ninguém viu”. Tudo funciona sem exposição pessoal — o produto é a marca.
O que é
O lançamento é a transição de “construindo em silêncio” para “o mundo sabe que isso existe”. A maioria dos indie hackers trata isso como um evento único (“lanço no Product Hunt e vejo o que acontece”). Os que têm sucesso tratam como processo de 3 fases com 4-8 semanas de preparação.
Por que importa
Um bom lançamento fornece:
- Primeiro batch de usuários reais (não amigos)
- Feedback concentrado em pouco tempo
- Prova social (Product Hunt badges, estrelas GitHub, testimonials)
- Backlinks e menções (SEO/GEO de longo prazo)
- Momentum psicológico para o fundador (validação emocional de que alguém se importa)
Um lançamento ruim não é fatal — a maioria dos SaaS de sucesso teve lançamentos medíocres. Mas um bom lançamento acelera meses de crescimento orgânico.
Como funciona
Fase 1 — Soft Launch (semanas 1-2)
Objetivo: Corrigir os 3 maiores atritos de onboarding antes que o público maior veja.
| Ação | Detalhe |
|---|---|
| Compartilhe com 50-100 pessoas | Entrevistados do Mom Test, lista de emails, colegas |
| Observe o onboarding | Onde travam? O que perguntam? O que confunde? |
| Corrija os 3 maiores atritos | Não tente perfeiçoar — resolva o que bloqueia |
| Peça testimonials | ”O que achou? Posso usar essa frase na página?” |
Fase 2 — Community Launch (semanas 3-4)
Objetivo: Validar messaging e canal de distribuição.
| Canal | Como usar | Formato |
|---|---|---|
| Indie Hackers | Post contando a história (não pitch) | “Show IH: I built X because Y” |
| r/SaaS, r/SideProject | Post honesto sobre o problema resolvido | ”I built X after struggling with Y for months” |
| r/learnprogramming, r/ObsidianMD | Post útil com menção orgânica | ”Here’s how I study using spaced repetition — I ended up building a tool for it” |
| Dev.to | Artigo técnico | ”How I built a Markdown vault parser in TypeScript” |
| Hacker News (Show HN) | Post técnico-focused | ”Show HN: [Nome] — [descrição técnica de 1 linha]“ |
| Twitter/X do projeto | Thread contando a jornada | ”I’ve been building @estudeme for X months. Here’s what I learned 🧵” |
Regra: contribua antes de promover. Se sua primeira ação em r/ObsidianMD é um post sobre seu produto, é spam. Se você ajuda na comunidade há semanas e menciona organicamente, é contribuição.
Fase 3 — Product Hunt Launch (semana 5+)
Preparação (30 dias antes):
| Dia | Ação |
|---|---|
| D-30 a D-15 | Criar conta no PH, engajar genuinamente (upvotar, comentar outros produtos) |
| D-14 a D-7 | Preparar assets: thumbnail (240×240), demo video (30-60s screencast), 5-8 screenshots, tagline (60 chars max) |
| D-6 a D-1 | Montar lista de 20-30 supporters, preparar posts para redes sociais, escrever first maker comment |
| D-Day | Lançar após 00:01 PST, responder TODOS os comentários em < 30 min, ficar online 12-16h |
Assets necessários:
| Asset | Spec |
|---|---|
| Thumbnail | 240×240px, ícone limpo, sem texto/gradiente |
| Demo video | 30-60s screencast mostrando o valor core, sem talking head |
| Screenshots | 5-8 com captions claros |
| Tagline | Max 60 chars: “Study smarter with spaced repetition for devs” |
| First comment | 200-400 palavras: por que construiu, que problema resolve, o que é diferente |
No dia:
- Stagger engajamento dos supporters nas primeiras 2 horas (parecer orgânico)
- Responder cada comentário pessoalmente (como @projeto, não como pessoa)
- Não pedir votos explicitamente (viola guidelines e trigga spam detection)
Re-launching
Cada feature major é oportunidade de re-launch:
- “EstudeMe v0.2 — agora com Study Buddy AI” → novo post no Indie Hackers
- “EstudeMe agora tem Obsidian plugin” → post no r/ObsidianMD + novo Show HN
- Major version → novo Product Hunt launch (permitido para novas versões)
Na prática
Timeline condensada para solo founder:
| Semana | Fase | Foco |
|---|---|---|
| 1-2 | Soft launch | 50-100 testadores, corrigir atritos |
| 3-4 | Community launch | Posts em 3-5 comunidades, artigo técnico |
| 5 | Product Hunt | Launch day com assets prontos |
| 6+ | Re-launch contínuo | Cada feature major = novo launch |
Armadilhas
-
Lançar sem soft launch. Se os primeiros 1.000 visitantes veem um produto com bugs de onboarding, a primeira impressão é permanente.
-
Tratar Product Hunt como “faz ou morre”. PH é um canal, não o destino. Muitos SaaS de sucesso nunca usaram PH. Se o resultado for medíocre, não é o fim.
-
Pedir votos explicitamente. “Please upvote my product!” é a melhor forma de ser shadowbanned. Diga “I launched on PH today, would love your feedback” — peça feedback, não votos.
-
Desaparecer após o launch day. O PH tem 24 horas de visibilidade. Depois, use o momentum para publicar updates, agradecer early adopters e integrar feedback.
-
Esperar demais para lançar. Se o MVP está funcional, lance. A vergonha de “ainda não está pronto” é menor que o custo de construir 3 meses a mais sem feedback.
Veja também
- 07 - O que é realmente um MVP — o que ter pronto antes do launch
- 13 - Posicionamento — Obviously Awesome — messaging para o launch
- 14 - SEO e GEO em 2026 — conteúdo de launch como SEO asset
- 15 - Product-led growth para bootstrapped — launch como topo do funil PLG
Referências
- Product Hunt — producthunt.com. Guidelines oficiais para makers e lançamentos.
- Lenny Rachitsky — Newsletter com dados sobre timing e estratégias de Product Hunt.
- Indie Hackers — indiehackers.com. Relatos de launches com métricas publicadas.
- Kahl, Arvid — Zero to Sold. Build in public como estratégia de launch contínuo.