Conseguir os primeiros utilizadores

As primeiras 10 publicações sobre a sua app quando ainda não tem utilizadores nem testemunhos

Dez modelos de publicação para uma app acabada de lançar, cada um com um objetivo, uma estrutura para preencher e a rede a que se adequa, mais a forma de os transformar num plano de duas semanas.

29 de agosto de 20267 min de leituraFundadores sem utilizadores nem testemunhosPortuguês

About this case study

Este guia descreve um processo repetível de escrita e publicação, não um resultado reportado por um cliente, e os dez modelos são pontos de partida para preencher, não textos para copiar tal e qual.

Ponto de partidaSem utilizadores nem citações

O que escreve10 publicações, uma sessão

Janela de publicação2 semanas

Não precisa de utilizadores para ter o que publicar

Lançou num fim de semana com o Lovable, o Bolt, o Cursor, o v0 ou o Replit. A app funciona, o domínio está no ar e depois abre o editor e a única coisa que lhe ocorre escrever é, outra vez, o link do lançamento. A maioria dos conselhos manda publicar testemunhos, resultados e casos práticos. Não tem nenhum deles, por isso não publica nada, e a app fica ali parada.

O erro é assumir que a matéria-prima do conteúdo são os resultados dos outros. No primeiro mês a matéria-prima são as suas próprias decisões: o problema que tinha, a folha de cálculo de que estava farto, a funcionalidade que cortou na terça-feira, o pressuposto que se revelou errado. Mais ninguém consegue escrever essas publicações, e elas são mais interessantes do que uma citação de cinco estrelas.

O que se segue são dez publicações. Cada uma tem um objetivo, uma estrutura para preencher e uma rede a que se adequa. Escreva-as todas de uma vez, enquanto ainda tem o desenvolvimento fresco na cabeça, e depois distribua-as por duas semanas.

Publicações 1 a 4: as que só o próprio consegue escrever

Vêm da sua própria história com o problema, por isso não precisam de utilizador nenhum.

1. O problema que tinha (Threads ou X). Objetivo: mostrar que construiu isto para si próprio e não como exercício. Estrutura: “Durante [período] andei sempre a [coisa concreta que o irritava]. Experimentei [solução óbvia] e não pegou porque [razão]. Por isso criei a [app] para fazer [uma coisa].” Mantenha o incómodo concreto — “perdi três faturas na caixa de entrada no último trimestre” vale mais do que “faturar é complicado”.
2. O improviso que substituiu (X). Objetivo: nomear o concorrente que as pessoas usam mesmo, que costuma ser uma folha de cálculo, um ficheiro de notas ou um grupo de conversa. Estrutura: “Antes da [app] fazia isto com [improviso]. Funcionou até [ponto de rutura]. É assim que o mesmo trabalho fica agora.” Junte uma imagem do improviso antigo; a confusão é o gancho.
3. A demonstração de 20 segundos (Reels do Instagram ou vídeo no Threads). Objetivo: provar que aquilo existe e funciona. Estrutura: uma gravação de ecrã, uma tarefa, do início ao fim, sem separador de abertura. O primeiro fotograma mostra o estado vazio e o último mostra o resultado. Legenda: “[Tarefa], em 20 segundos.” Dispense a narração e ponha texto no ecrã nos dois momentos que interessam.
4. A decisão em que se enganou (Threads). Objetivo: ganhar confiança mais depressa do que qualquer publicação sobre funcionalidades. Estrutura: “Comecei por criar [funcionalidade] porque assumi que [pressuposto]. Depois [o que aconteceu mesmo]. Removi-a e criei [substituição] em vez disso.” Esta atrai sempre respostas de outros builders, e são eles que o partilham na primeira semana.

Publicações 5 a 7: mostrar a coisa e traçar uma linha

As três do meio tornam o valor legível e começam conversas enquanto a audiência ainda é pequena.

5. O antes e depois (carrossel no Instagram). Objetivo: explicar o valor em dois fotogramas a quem não vai ler um parágrafo. Estrutura: o primeiro slide é o antes desarrumado, o segundo é o mesmo trabalho dentro da sua app, o terceiro é uma frase a dizer o que mudou. Use exatamente os mesmos dados nos dois lados para a comparação ser honesta.
6. A publicação “para quem isto não é” (X ou Threads). Objetivo: afinar para quem é dizendo em voz alta para quem não é. Estrutura: “A [app] não é para [grupo], [grupo] nem [grupo]. É para [uma pessoa concreta] que precisa de [uma coisa concreta].” Traz mais respostas do que uma promessa vaga, porque a pessoa certa reconhece-se na exclusão.
7. Uma pergunta a que precisa mesmo de resposta (Threads). Objetivo: começar conversas antes de ter audiência, porque responder a uma pergunta custa muito menos a um desconhecido do que clicar num link. Estrutura: uma linha de contexto, uma pergunta, sem link. “Estou a decidir entre [A] e [B] para [caso de uso]. Se faz [atividade] todas as semanas, qual preferia?” Depois responda a toda a gente.

Quatro das dez publicações são visuais. Os modelos de marca compõem-nas automaticamente com as suas cores e tipografia, para que dez publicações de um fundador a solo não pareçam dez contas diferentes.

Publicações 8 a 10: o detalhe, o pedido e os números

As três últimas são as que os fundadores saltam, e são as que transformam leitores em pessoas que respondem.

8. A captura de ecrã com um detalhe assinalado (Instagram ou X). Objetivo: uma captura de ecrã inteira lê-se como ruído, um único detalhe assinalado lê-se como um argumento. Estrutura: corte bem junto, desenhe uma seta ou uma caixa num só elemento e escreva uma frase sobre a razão de ser desse elemento. Um detalhe por publicação — ecrãs e semanas não lhe faltam.
9. O pedido “o que devo construir a seguir” (Threads ou X). Objetivo: transformar um roadmap privado numa conversa pública e perceber o que as pessoas querem antes de gastar um fim de semana a construir. Estrutura: “A seguir posso fazer [A], [B] ou [C]. A dá [resultado], B dá [resultado], C dá [resultado]. Qual mudava a sua semana?” Lance o vencedor e publique o resultado uma semana depois.
10. Os números honestos da primeira semana (X). Objetivo: a credibilidade do build in public vem de publicar números enquanto ainda são pequenos. Estrutura: “Semana um: [visitantes] visitantes, [registos] registos, [regressos] pessoas que voltaram. É isto que acho que correu mal.” Números pequenos com uma leitura verdadeira chegam mais longe do que números redondos sem interpretação nenhuma.

Transformar dez rascunhos num plano de duas semanas

Dez rascunhos num documento não são um plano de distribuição. É entre escrevê-los e publicá-los com ritmo fixo que morre a maior parte do primeiro conteúdo, por isso vale a pena montar a parte mecânica uma vez.

Comece por apontar a Amplispect ao site da sua app. Ela lê a proposta, o público e o tom que já escreveu na landing page e cria um espaço de trabalho a partir daí, para que tudo o que for gerado ao lado dos seus rascunhos soe ao seu produto e não a texto genérico de startup. Cole lá as suas dez publicações.

As quatro publicações visuais — a demonstração, o antes e depois, o carrossel e a captura assinalada — passam pelos modelos de marca. Depois o editor dá-lhe uma pré-visualização por rede, por isso vê a versão do X a cortar e a legenda do Instagram a dobrar antes de entrar na fila, e não depois de já ter sido publicada.

Depois agende: cinco publicações por semana durante duas semanas, uma por dia útil, alternando uma publicação de história com uma visual. A Amplispect publica no Instagram, no Threads e no X, e nada sai sem a sua revisão. Ponha as duas perguntas, as publicações 7 e 9, em dias em que sabe que está disponível, porque uma pergunta sem resposta é pior do que não perguntar. Responda a todos os comentários durante as duas semanas — com dez publicações e sem audiência, as respostas são quase todo o seu alcance.

O que duas semanas disto lhe dão realisticamente

Dez publicações, cinco por semana, cada uma com uma razão para existir. Realisticamente, isso são um punhado de respostas, duas ou três conversas com pessoas que têm o problema e uma frase bastante mais afiada para descrever o que construiu. Não é um pico de lançamento. É o primeiro ciclo repetível: as respostas às publicações 6, 7 e 9 dizem-lhe o que escrever na terceira semana e, a essa altura, já deve ter um primeiro utilizador real sobre quem escrever.

O limite a respeitar

Não invente a prova social que não tem. Nada de testemunhos fabricados, capturas de ecrã emprestadas ou “os utilizadores estão a adorar” quando são quatro e dois são amigos seus. Identifique como modelados os números modelados ou projetados. Estas dez publicações funcionam sem utilizadores precisamente porque todas são verificavelmente suas, e uma única citação inventada custa-lhe a única vantagem que tem.

Ir mais fundo

Para onde ir depois de escrever e agendar as primeiras dez:

Temaso que publicar sobre a minha appprimeiras publicações para uma appredes sociais para uma app novaideias de conteúdo para appspublicações build in public

Perguntas frequentes

O que publicar sobre a minha app quando ainda ninguém a usa?

Publique aquilo que só o próprio sabe: o problema que tinha, o improviso que substituiu, a decisão em que se enganou e o que está a pensar construir a seguir. Nada disso precisa de utilizadores e é mais concreto do que qualquer testemunho lhe daria.

O que faz uma boa primeira publicação sobre uma app nova?

Uma ideia, um detalhe concreto e nenhum link. A primeira publicação mais forte costuma ser a história de origem com um número ou um momento específico, porque explica ao mesmo tempo o que a app faz e porque a criou.

Com que frequência devo publicar sobre uma app nova?

Cinco publicações por semana durante as duas primeiras semanas chegam para testar o que resulta sem gastar todo o material. A Amplispect agenda a série inteira no Instagram, no Threads e no X de uma só vez, e cada publicação continua a esperar pela sua revisão antes de sair.

Em que rede devo publicar a minha app primeiro?

O Threads e o X servem as publicações escritas, porque premeiam o detalhe e facilitam as respostas. O Instagram serve a demonstração, o carrossel e a captura assinalada. A Amplispect publica nas três, por isso pode correr o mesmo conjunto de dez em todas em vez de escolher.