About this case study
Este é um modelo que pode executar sozinho, não um resultado reportado por um cliente nem uma promessa de alcance.
Como funciona a rotação de quatro semanas
Construiu a app num fim de semana com o Lovable, o Bolt, o Cursor ou o Replit, e construir em público é a distribuição mais barata que lhe resta. Encrava por uma razão banal: nas semanas em que não sai nada de dramático, não publica nada e a conta fica em silêncio durante quinze dias. Um modelo resolve isso, porque é o tema que decide o que publica antes de precisar de se sentir inspirado.
A rotação dura quatro semanas. A semana 1 é o problema e para quem ele existe. A semana 2 é o progresso e as decisões por trás dele. A semana 3 é a prova: números, evidências e lições. A semana 4 é o pedido: feedback, testers e o que vem a seguir. Depois recomeça na semana 1, com um mês de material novo para o dizer.
Dentro de cada semana, cinco publicações assumem um de cinco papéis: problema, progresso, prova, pedido e lição. O papel dá-lhe a forma, o tema dá-lhe o assunto, a rede dá-lhe o tamanho. O Threads e o X ficam com os textos, o Instagram fica com uma publicação visual por semana. Copie as checklists abaixo e preencha os parênteses.
Semanas 1 e 2: o problema, depois o progresso
A semana 1 faz um desconhecido reconhecer a sua própria situação e não exige nenhuma funcionalidade nova. A semana 2 mostra movimento, e só resulta se publicar a decisão em vez do diff.
- Semana 1 · Segunda · Problema · Threads e X — “A maioria dos [público] continua a [processo manual]. Isso custa-lhes [tempo ou dinheiro] por semana. É contra isso que estou a construir.”
- Semana 1 · Terça · Progresso · Threads e X — A menor parte funcional que toca no problema, com uma captura de ecrã: “Esta é a parte que substitui [passo]. Demorou [n] dias.”
- Semana 1 · Quarta · Prova · Instagram — Um cartão com o antes e o depois: “[Método antigo]: catorze passos. [Método novo]: dois.” Menos de doze palavras na imagem.
- Semana 1 · Quinta · Pedido · Threads e X — “Se hoje faz [a tarefa], como é que a resolve na prática? Vou ler todas as respostas.” Depois responda a todas.
- Semana 1 · Sexta · Lição · Threads e X — “Assumi que [suposição]. Três conversas depois, a queixa real é [realidade].”
- Semana 2 · Segunda · Progresso · Threads e X — “A [funcionalidade] já está disponível. Existe porque [utilizador] não conseguia [fazer algo].” Uma frase, uma captura.
- Semana 2 · Terça · Lição · Threads e X — “Escolhi [opção A] em vez de [opção B]. A [opção B] teria levado três semanas e servido menos gente.”
- Semana 2 · Quarta · Prova · Instagram — Um antes e depois de um ecrã que reconstruiu, com legenda sobre o que mudou para quem o usa.
- Semana 2 · Quinta · Progresso · Threads e X — A correção sem glamour: “Passei [n] horas em [problema aborrecido] esta semana. Ninguém vai reparar, e é esse o objetivo.”
- Semana 2 · Sexta · Pedido · Threads e X — “A seguir é [A] ou [B]. Qual é que usaria mesmo? Uma resposta decide.”
Semanas 3 e 4: a prova, depois o pedido
Um número honesto vale mais do que cinco afirmações vagas e, se ainda não tem números, as evidências servem: citações, conversas de apoio, utilização real. A semana 4 pede algo concreto, porque “vão espreitar” dá resultados vagos.
- Semana 3 · Segunda · Prova · Threads e X — Um número com o denominador: “[n] pessoas registaram-se este mês, [m] voltaram na segunda semana. Isto é o que essas [m] têm em comum.”
- Semana 3 · Terça · Lição · Threads e X — “Esperava [suposição]. Os dados diziam [realidade], por isso removi [funcionalidade].”
- Semana 3 · Quarta · Prova · Instagram — Uma captura das suas análises com os eixos legíveis, mais uma linha de contexto. Nunca corte um eixo para a curva parecer mais inclinada.
- Semana 3 · Quinta · Prova · Threads e X — Um utilizador pelas suas palavras, com autorização: “Alguém descreveu isto como [citação]. É agora o título da landing page.”
- Semana 3 · Sexta · Lição · Threads e X — “[Canal ou tática] deu [resultado] em [tempo]. Vou parar, e é isto que tentaria em vez disso.”
- Semana 4 · Segunda · Pedido · Threads e X — “Procuro [n] [tipo de pessoa] para experimentar [funcionalidade] esta semana. Respondam e envio o convite hoje.”
- Semana 4 · Terça · Progresso · Threads e X — “Três de vocês disseram [queixa]. Está corrigido desde esta manhã.”
- Semana 4 · Quarta · Prova · Instagram — O próximo mês em cartão, em três linhas: o que vai construir, o que decidiu não construir e quando.
- Semana 4 · Quinta · Pedido · Threads e X — O convite, uma vez por mês, sem pedir desculpa: “A [app] faz [resultado] para [público]. Experimentar é grátis, link em baixo.”
- Semana 4 · Sexta · Lição · Threads e X — O balanço do mês: uma coisa que resultou, uma que não, um número e uma linha sobre o mês seguinte.
20 ideias de publicações build in public que nunca se esgotam
Quando um espaço fica vazio, use a ideia que corresponde ao papel. Cada uma funciona quer tenha lançado algo esta semana, quer não.
- Problema — O improviso que os seus utilizadores pagam hoje, com o preço real ao lado.
- Problema — Uma captura da folha de cálculo ou da página de Notion que a sua app substitui.
- Problema — A pergunta que lhe fazem sempre por mensagem, respondida em público.
- Problema — Para quem a app não serve, dito sem rodeios.
- Progresso — A funcionalidade que lançou, numa frase e numa captura de ecrã.
- Progresso — O que apagou, e porque é que a app ficou melhor sem isso.
- Progresso — Uma gravação de um fluxo que dava quatro cliques e agora dá um.
- Progresso — A sua semana real: horas a construir, horas em apoio, horas em distribuição.
- Prova — Uma métrica com o denominador à vista.
- Prova — Uma conversa de apoio, anonimizada, que se transformou numa correção.
- Prova — Uma citação de um utilizador que não foi escrita por si.
- Prova — Quanto lhe custa manter a app este mês, item a item.
- Pedido — Duas opções para o próximo passo, decididas com uma única resposta.
- Pedido — Um apelo a testers com um número e um prazo.
- Pedido — Um pedido de feedback sobre um só ecrã, com a imagem em anexo.
- Pedido — O convite mensal, com link e sem pedir desculpa.
- Lição — A suposição que um utilizador destruiu este mês.
- Lição — Uma mudança de preços e o que aconteceu depois.
- Lição — A ferramenta ou o canal que deixou de usar, e o que veio no lugar.
- Lição — O que faria de forma diferente se recomeçasse na segunda-feira.
Como executar este modelo na Amplispect
O modelo sobrevive ao primeiro mês à custa de força de vontade, e ao terceiro porque há outra coisa a segurar o calendário. Na Amplispect isso começa com um espaço de trabalho criado a partir do seu site: cole o URL e ele recolhe a sua oferta, o seu público e o seu tom de marca, para que os rascunhos soem ao produto e não a uma conta genérica de fundador.
Defina a cadência em cinco publicações por semana e deixe a Amplispect gerar a semana seguinte. Cada publicação gerada chega com um papel e uma data associados, que é exatamente aquilo de que este modelo é feito, por isso o seu trabalho é trocar os papéis pelos que o tema da semana pede e editar o texto com as sugestões à frente. Reveja e agende a semana inteira numa só sessão: o editor pré-visualiza cada publicação por rede, por isso uma legenda demasiado longa para o X, ou uma publicação de Instagram sem imagem, é apanhada antes de entrar na fila. Nada é publicado sem a sua aprovação.
Depois vem a parte diária, uns quinze minutos: as respostas. Os comentários das contas ligadas sincronizam com respostas propostas que aprova ou reescreve, para que o pedido de quinta-feira se transforme numa conversa. No fim do mês, deixe a vista de desempenho escolher a rotação seguinte. Se a semana de prova rendeu mais do que todas as outras, faça duas semanas de prova e reduza o problema a uma única publicação.
O que um mês assim lhe dá mesmo
Vinte publicações, cinco delas pedidos diretos, quatro com um número real associado, e um registo público de todas as decisões que tomou. O resultado realista não é uma publicação viral. É que quem o segue consegue descrever o que a sua app faz sem a abrir, e que nunca mais se senta numa terça-feira sem saber o que dizer. Seguidores, registos e instalações continuam a ser resultados a medir, não números que um calendário possa prometer.
O limite: não enfeite os números
Construir em público perde a sua única vantagem no momento em que os números são enfeitados. Publique o denominador com a métrica, identifique como tal tudo o que for modelado ou projetado, e nunca corte o eixo de um gráfico para favorecer uma curva. A mesma honestidade vale para a cadência: cinco publicações por semana que consegue manter valem mais do que quinze durante quinze dias seguidas de silêncio. Se uma semana estiver mesmo vazia, publique uma lição, não um marco inventado.
Aprofundar
O resto do cluster e as duas páginas de produto em que este modelo assenta.
- Build in Public: Uma Cadência de Publicação Que Traz Utilizadores, Não Só SeguidoresO raciocínio por trás da cadência que este modelo agenda, e como escolher uma que consiga manter.
- Modelo de calendário de conteúdos para lançar uma app: 3 semanas, dia a diaA versão de semana de lançamento deste calendário, para o mês em que finalmente lança.
- Typefully vs Amplispect para quem faz build in publicComo uma ferramenta de escrita centrada em texto se compara com um espaço de trabalho que planeia, agenda e trata das respostas.
- Como escrever um changelog que traz utilizadores de volta (e atrai novos)Transforme as publicações de progresso das semanas 2 e 4 num changelog que traz as pessoas de volta.
- Como Distribuir uma App: O Guia Completo para Fundadores que Já Construíram AlgoO quadro completo da distribuição de que este calendário é apenas uma peça.
- Gerador de calendário de conteúdos com IAGere a semana seguinte na sua cadência, com um papel e uma data em cada publicação.
- Agendador para Instagram, Threads e XAgende a semana para as três redes que este modelo usa, com pré-visualização por rede.
Perguntas frequentes
Com que frequência se deve publicar ao construir em público?
Cinco publicações por semana é a cadência que este modelo assume, porque preenche um dia útil de cada vez e ainda deixa tempo para responder. Três por semana também funciona, desde que mantenha a rotação. O que falha é um período intenso de quinze dias seguido de um mês de silêncio.
O que publico se esta semana não lancei nada?
Use uma publicação de problema, de prova ou de lição. Três dos cinco papéis não exigem código novo: o problema que a sua app resolve, um número que já tem ou algo em que se enganou. É por isso que a rotação existe.
Que redes funcionam melhor para construir em público?
O Threads e o X levam as publicações de texto, porque ambos premeiam atualizações curtas e concretas e é aí que acontecem as respostas. O Instagram fica com a publicação visual da semana. A Amplispect publica nessas três; tudo o que fizer no LinkedIn, no Reddit ou no TikTok continua a ser trabalho manual.
É possível automatizar um calendário de conteúdos build in public?
O planeamento sim. A Amplispect gera a semana na sua cadência com um papel e uma data em cada publicação, e você troca os papéis pelos que este modelo pede. A publicação continua a esperar pela sua revisão, e as respostas são suas para escrever.