About this case study
Este texto descreve um processo repetível de marketing de lançamentos, não um resultado reportado por um cliente nem a promessa de que uma atualização isolada trará de volta utilizadores inativos.
Cada lançamento é conteúdo que já pagou
Em 2026, o desenvolvimento raramente é o estrangulamento. Com o Lovable, o Bolt, o Cursor, o v0 ou o Replit é possível lançar três ou quatro melhorias reais numa semana. O que quase ninguém faz é contá-lo a alguém. O trabalho entra em produção, o histórico do git cresce e só repara quem já tem a aplicação aberta.
Um changelog é o conteúdo mais barato que alguma vez vai escrever, porque o pensamento já estava feito antes de abrir o editor. Não está a inventar um tema. Está a relatar um. A única decisão que resta é se o escreve como um diff ou como um resultado.
Um diff diz: “Adicionada a exportação em lote para CSV.” Um resultado diz: “Já consegue trazer um mês de dados para uma folha de cálculo com um clique, por isso o relatório do cliente deixa de ser um trabalho de reescrita.” O mesmo lançamento, um leitor completamente diferente. A primeira frase foi escrita para si. A segunda foi escrita para quem está a decidir se vale a pena voltar a abrir a sua aplicação.
Escrito como resultados, um changelog faz duas coisas ao mesmo tempo. Chega ao utilizador que se foi embora precisamente porque faltava aquilo que agora existe. E mostra a quem chega pela primeira vez algo que nenhuma landing page consegue fingir: um produto que está visivelmente a avançar.
O modelo de entrada do changelog
Todas as entradas respondem às mesmas perguntas pela mesma ordem. Quatro linhas curtas, uma captura de ecrã, um link:
- O que mudou, numa frase que alguém de fora do código perceba. Sem nomes internos, sem números de tarefa, sem “refatorámos a camada de sincronização”.
- Para quem é, descrito como um comportamento e não como um plano de subscrição: “se revê publicações no telemóvel”, “se gere mais do que uma marca”.
- O que essa pessoa passa a conseguir fazer e não conseguia na semana passada. É esta a linha que gera o clique, por isso escreva uma capacidade e não o nome de uma funcionalidade.
- Porque é que isso importa, numa oração: o incómodo que desaparece, o passo que é eliminado, o improviso que fica reformado.
- Uma captura de ecrã ou um clipe curto da própria coisa, recortado exatamente na alteração. Uma imagem do novo estado vale mais do que qualquer adjetivo que lhe possa juntar.
- Um link, direto para o ecrã onde a alteração vive. Não a página inicial — ninguém vai andar à procura.
Que lançamentos merecem uma publicação pública
Nem todos. Se cada atualização de dependências virar anúncio, a sua audiência aprende que as suas publicações podem ser ignoradas em segurança — e o único lançamento que interessava é ignorado juntamente com os outros. É a contenção que mantém o canal digno de leitura.
A regra é suficientemente estreita para ser aplicada em cinco segundos: um lançamento merece publicação quando muda o que alguém consegue fazer, elimina um motivo declarado que levou alguém a sair, ou é visível assim que a aplicação abre. Tudo o resto — correções, desempenho, ajustes de texto — fica na página do changelog mas não recebe publicação própria.
Para quem lança semanalmente, isto costuma assentar numa divisão simples. Tudo entra na entrada do changelog. Cerca de um lançamento por semana passa o critério para publicação pública. Uma vez por mês, os pequenos são agrupados num único resumo do género “o que saiu em agosto”, para que o trabalho invisível também tenha o seu momento.
Se numa semana nada passar o critério, não fabrique um anúncio. Publique outra coisa: uma decisão que reverteu, uma limitação com que esbarrou, uma dúvida em que está encalhado. É a sua cadência de build in public que sustenta as semanas que o roadmap não sustenta.
Transformar uma entrada numa publicação por rede
A entrada é a fonte. Cada rede recebe a mesma notícia com a sua própria forma — nunca o mesmo bloco de texto colado três vezes:
- Instagram: comece pelo visual. A captura recortada ou uma gravação de ecrã de cinco segundos é a publicação; a legenda diz para quem é e o que a pessoa passa a conseguir fazer.
- Threads: escreva em tom de conversa, como se estivesse a contar a quem pediu a funcionalidade. “Pediram isto. Já está no ar.” Depois deixe a conversa aberta e responda ao que vier.
- X: a versão mais curta que ainda se sustenta sozinha. Uma linha sobre a capacidade, a captura, o link. Empurre o raciocínio para uma resposta em vez da primeira publicação.
- Mantenha o mesmo link de destino nas três, para perceber que rede levou de facto pessoas ao ecrã novo.
- Escreva as três na mesma sessão, enquanto o lançamento ainda está fresco. Voltar ao assunto dois dias depois transforma sistematicamente um resultado outra vez num diff.
O fluxo semanal, do início ao fim
Dê dias fixos ao ciclo para que ele sobreviva a uma semana cheia. Lançar à quarta-feira. Escrever a entrada à quinta, enquanto ainda se lembra do motivo pelo qual construiu aquilo. Publicar na sexta de manhã e manter a tarde livre para responder a pessoas. Quatro espaços no calendário, sem decisões para repetir.
Na Amplispect, a entrada vai uma vez para o editor e passa a ser a fonte das três versões. A pré-visualização por rede mostra como a legenda e a imagem vão realmente aparecer no Instagram, no Threads e no X antes de qualquer coisa entrar na fila, e a validação apanha a legenda que ultrapassa o limite de uma rede ou a imagem com o formato errado — as duas falhas que normalmente só se descobrem ao vivo.
Agende o conjunto em vez de publicar à mão. Uma publicação de lançamento que sai à hora escolhida é uma publicação que pode preparar na quinta e continuar presente para ela na sexta, o que importa mais do que a hora exata que escolher.
Depois as respostas voltam para uma única fila em vez de três aplicações. A Amplispect sincroniza os comentários suportados para o espaço de trabalho e consegue redigir uma resposta, mas nada sai sem que a tenha lido e aprovado. Responder às primeiras perguntas sobre uma funcionalidade nova dentro da hora seguinte é a razão de ser da tarde de sexta livre.
Ao fim de um trimestre, olhe para as publicações de lançamento e pergunte que tipo de atualização gerou respostas verdadeiras. Os fundadores costumam ficar surpreendidos: o pequeno incómodo que desapareceu supera muitas vezes a funcionalidade principal, porque mais gente o tinha sentido na pele. Esse sinal pertence ao próximo roadmap e não apenas à próxima legenda.
O que isto produz de forma realista
Ao fim de um trimestre a lançar todas as semanas, tem cerca de doze publicações de lançamento, uma página de changelog que se lê como um produto com movimento e um registo de que tipo de atualizações as pessoas respondem realmente. Esse registo é a parte valiosa: diz-lhe o que anunciar a seguir e, muitas vezes, o que construir a seguir. Utilizadores que regressam e novos registos continuam a ser resultados a medir, não números que este processo possa prometer.
A regra de segurança
Nunca anuncie algo que não esteja totalmente disponível para quem clica. Uma publicação de lançamento que aterra numa feature flag, numa lista de espera ou num ecrã que não se parece nada com a captura custa mais confiança do que a atualização consegue devolver. Lance, capture o que foi lançado e só depois publique.
Aprofundar
Onde é que as publicações de lançamento encaixam no resto da sua distribuição:
- Transforme a sua landing page em 30 dias de publicaçõesAproveite as páginas que já tem para as semanas em que não lança nada.
- Build in Public: Uma Cadência de Publicação Que Traz Utilizadores, Não Só SeguidoresO ritmo de publicação que sustenta as semanas entre lançamentos.
- As primeiras 10 publicações sobre a sua app quando ainda não tem utilizadores nem testemunhosO que publicar antes de ter um changelog digno de ser anunciado.
- Como fazer crescer uma app com um ciclo semanal de aquisiçãoComo um lançamento semanal se transforma num ciclo de aquisição repetível.
- Como Distribuir uma App: O Guia Completo para Fundadores que Já Construíram AlgoA visão completa de como pôr uma aplicação à frente das pessoas depois de a construir.
- Agendador de redes sociaisEscreva o lançamento uma vez, pré-visualize por rede e agende o conjunto todo de uma assentada.
- Gestão de comentáriosReúna todas as respostas a uma publicação de lançamento numa fila que revê antes de responder.
Perguntas frequentes
O que deve incluir uma entrada de changelog?
O que mudou em linguagem simples, para quem é, o que a pessoa passa a conseguir fazer, porque é que isso importa, uma captura de ecrã da alteração e um link para o ecrã exato. Os números de versão e os nomes internos são opcionais; a capacidade não é.
Devo publicar nas redes sociais sobre todas as atualizações?
Não. Publique quando um lançamento muda o que alguém consegue fazer, elimina um motivo que levou alguém a sair ou é visível assim que a aplicação abre. Correções e trabalho de desempenho ficam na página do changelog e podem ser agrupados num resumo mensal.
Como se anuncia uma funcionalidade nova nas redes sociais?
Escreva primeiro o resultado e depois adapte a cada rede: uma publicação visual no Instagram, uma conversacional no Threads e a versão mais curta possível no X. Mantenha o mesmo link de destino nas três para ver que rede trouxe tráfego.
As notas de lançamento funcionam mesmo como marketing?
Funcionam, quando são escritas para os utilizadores e não para a equipa. São o único conteúdo em que o trabalho já está feito, dão a utilizadores inativos um motivo concreto para voltar e mostram a quem chega de novo que o produto continua a melhorar.