About this case study
Este é um horário semanal modelado que pode copiar e ajustar, não um resultado reportado por um cliente nem a promessa de que um certo número de horas gera utilizadores.
A regra dos 50/50 não existe
A pergunta aparece todas as semanas nos fóruns de indie hackers: quanto tempo devo dedicar ao marketing e quanto ao desenvolvimento? A resposta popular é 50/50, e está errada da mesma forma que qualquer rácio fixo está errado. Uma divisão fixa parte do princípio de que o trabalho de distribuição tem sempre o mesmo tamanho, quando na verdade muda de forma pelo menos três vezes nos primeiros meses de uma app.
A versão de 2026 da pergunta é diferente, porque a metade do desenvolvimento encolheu. É possível passar de uma ideia a uma app publicada e funcional com Lovable, Bolt, Cursor, v0 ou Replit num fim de semana. O estrangulamento mudou de sítio. Dedicar metade da semana a programar quando a app já faz aquilo que promete não é equilíbrio, é um esconderijo confortável.
Portanto, aqui vai a resposta com opinião. Pré-lançamento: cerca de 80 por cento de desenvolvimento e 20 por cento de distribuição, aproximadamente 6 horas por semana em distribuição. Semana de lançamento: 30 por cento de desenvolvimento e 70 por cento de distribuição, cerca de 20 horas. Planalto pós-lançamento: 60 por cento e 40 por cento, cerca de 12 horas. As percentagens exatas importam muito menos do que o facto de se moverem e de saber em que fase está.
As três semanas-tipo seguintes assumem cerca de 30 horas de trabalho concentrado. Se a sua semana real são 12 horas em cima de um emprego, reduza todas as linhas na mesma proporção e mantenha a ordem. O que não deve fazer é calcular a média das três fases, obter um número confortável e chamar-lhe estratégia.
Pré-lançamento: 6 horas de distribuição
Ainda não está a vender. Está a reunir uma audiência com o formato aproximadamente certo e a aprender as palavras que ela usa, para que a semana de lançamento tenha onde aterrar.
- 2 horas, à segunda-feira, numa só sessão: gerar a semana de publicações a partir do espaço de trabalho, ler todas, reescrever as que soam a folheto, apagar as que ainda não são verdade e agendar as restantes para Instagram, Threads e X.
- 1 hora: escrever um texto mais longo sobre o problema, não sobre o produto, e publicá-lo onde a sua audiência já lê.
- 1 hora: dez respostas genuínas a outras pessoas do seu nicho. Sem links, sem argumentário, sem dar a ninguém a sensação de estar a ser abordado.
- 1 hora: falar com duas pessoas que têm o problema. Uma mensagem direta, uma chamada ou um comentário debaixo de uma queixa sobre um concorrente contam todos.
- 30 minutos: atualizar a landing page para que descreva aquilo que construiu de facto esta semana.
- 30 minutos no total, cinco a dez minutos por dia: responder aos comentários nas suas próprias publicações.
- Sobram 24 horas para desenvolver, mais do que a maioria dos fundadores julga ter.
Semana de lançamento: 20 horas de distribuição
Esta é a única semana em que o desenvolvimento perde de propósito. Congele o código na sexta-feira anterior e só lhe toque para corrigir erros que impeçam o lançamento.
- 4 horas no fim de semana anterior: gerar e editar a semana de lançamento inteira numa só sessão, todos os dias e as três redes, deixando as publicações do dia do lançamento para o fim.
- 2 horas: preparar o que não são publicações. O vídeo de demonstração, três capturas de ecrã e o parágrafo único que vai colar em todos os formulários de diretórios.
- 3 horas no dia do lançamento, só respostas: cada comentário, citação e mensagem direta respondidos na hora, porque é nessa hora que o algoritmo e as pessoas estão a prestar atenção.
- 2 horas por dia no resto da semana, em dois blocos: respostas, seguimentos e as pessoas que disseram "interessante, fala comigo mais tarde".
- 2 horas: os canais manuais que nenhum agendador publica por si. Uma publicação no Reddit numa comunidade onde já é habitual, um texto no LinkedIn, um Show HN e um email a todos os que alguma vez perguntaram pela app.
- 1 hora à sexta-feira: escrever em frases simples o que gerou resposta e o que não gerou, para que a semana seguinte não seja adivinhação.
- 10 horas para desenvolver, o que na prática significa correções, textos de onboarding e aquela coisa que três pessoas pediram.
Planalto pós-lançamento: 12 horas de distribuição
O pico desapareceu, o gráfico está plano e é nesta fase que a maioria dos fundadores a solo deixa discretamente de publicar. O horário existe para tornar parar mais difícil do que continuar.
- 2 horas, à segunda-feira, numa só sessão: rever, editar e agendar a semana gerada. É a única sessão em que abre o calendário.
- 3 horas: uma peça substancial por semana, como um changelog, uma análise ou um guia curto, escrita de forma a poder ser cortada em várias publicações.
- 2 horas: distribuição que o agendador não faz. Uma comunidade, uma troca de newsletters, uma proposta a um podcast, um email de parceria.
- 2 horas: falar com cinco pessoas que se registaram e nunca voltaram. Perguntar o que esperavam que acontecesse.
- 2 horas à sexta-feira: ler a vista de desempenho, anotar que tipo de publicação gerou respostas e deixar que a semana seguinte reflita isso.
- 1 hora no total, dez a quinze minutos por dia: respostas e comentários, mais nada.
- 18 horas para desenvolver, e agora construa aquilo que essas cinco conversas lhe disseram para construir.
Porque é que uma sessão de revisão vence a publicação diária
A discussão dos 50/50 nunca se resolve porque as pessoas comparam horas sem comparar formatos. Quatro horas de desenvolvimento são um bloco. Quatro horas de distribuição feitas à mão, um pouco por dia, são quinze mudanças de contexto, e cada mudança custa-lhe o estado mental que tinha sobre o código. As horas parecem iguais numa folha de registo e não são iguais na sua cabeça.
Por isso concentre-as. A Amplispect cria um espaço de trabalho a partir do seu site, recolhendo a oferta, a audiência e o tom de voz da marca, e depois gera a semana de publicações na cadência que definir, cada uma com um papel e uma data. Abre essa semana uma vez, lê tudo, reescreve as publicações sem vida, apaga as que ainda não são verdade e agenda as que sobrevivem. As pré-visualizações e validações por rede fazem com que apanhe a legenda que não funciona no X antes de entrar na fila, e não depois.
É essa a linha das duas horas de segunda-feira em cada uma das três semanas acima. Tudo o que fica na coluna da distribuição é trabalho que uma ferramenta realmente não pode fazer por si, como as mensagens diretas, a publicação na comunidade e as chamadas com utilizadores, ou os dez minutos diários a responder a quem respondeu. Os comentários das redes suportadas sincronizam para o mesmo espaço de trabalho e podem ser respondidos a partir de rascunhos revistos, o que mantém o bloco diário como um bloco em vez de uma visita a três aplicações.
Nada é publicado sem que o leia primeiro. É essa a troca: o horário protege as suas horas de desenvolvimento tornando as horas de distribuição previsíveis e limitadas, e não retirando o seu nome das publicações.
O que o horário lhe dá de facto
Ao fim de um mês tem um hábito de distribuição que sobrevive a uma má semana: uma sessão de revisão que consegue defender no calendário, dez minutos diários suficientemente baratos para manter e um registo escrito de que publicações geraram respostas. Isso é uma prática que compõe e uma resposta real à questão do tempo. Não é um número de tráfego, e nenhum horário lho pode prometer.
Um calendário não cria procura
Publicar com regularidade não cria procura por uma app de que ninguém precisa. Se oito semanas consistentes não produzirem respostas, registos nem perguntas, o horário está a funcionar corretamente e a dizer-lhe algo útil: o problema está na oferta, na audiência ou na app. Mude uma dessas coisas antes de acrescentar horas de publicação.
Aprofundar
O resto do conjunto, se quiser as peças que este horário parte do princípio que já tem:
- Marketing de apps para programadores que odeiam marketingO que fazer com as horas de distribuição quando o próprio trabalho é a parte que detesta.
- Build in Public: Uma Cadência de Publicação Que Traz Utilizadores, Não Só SeguidoresUma cadência para a semana gerada, para que as publicações tenham algo honesto a dizer numa terça-feira calma.
- Como Distribuir uma App: O Guia Completo para Fundadores que Já Construíram AlgoO quadro completo de como uma app encontra utilizadores depois de estar construída e publicada.
- Como fazer crescer uma app com um ciclo semanal de aquisiçãoO mesmo ritmo semanal quando já são mais do que uma pessoa a fazer o trabalho.
- Porque é que ninguém usa a sua app (e a falha de distribuição por trás disso)O que verificar primeiro quando a semana de planalto nunca se transforma em crescimento.
- O agendadorRever, validar e agendar uma semana para Instagram, Threads e X numa só sessão.
- Criar um espaço de trabalhoCriar um espaço de trabalho a partir do seu site e ver a primeira semana gerada.
Perguntas frequentes
Quanto tempo deve um indie hacker dedicar ao marketing?
Depende da fase, não de um rácio fixo. Cerca de 20 por cento da semana antes do lançamento, até 70 por cento durante a semana de lançamento e à volta de 40 por cento quando o pico assenta. Numa semana de 30 horas, isso são aproximadamente 6, 20 e 12 horas.
A regra dos 50/50 entre desenvolvimento e marketing faz sentido?
É um bom slogan e um mau horário. Uma divisão fixa ignora que a semana de lançamento precisa de muito mais distribuição do que o mês anterior e que um planalto precisa de mais do que um pré-lançamento. Mova o rácio com a fase.
É possível fazer marketing de uma app em poucas horas por semana sozinho?
Sim, se agrupar o trabalho. Gerar e rever uma semana de publicações numa só sessão e depois dedicar dez minutos por dia a respostas cabe em poucas horas. O que não cabe é inventar cada publicação no próprio dia em que a publica.
E se publicar de forma consistente e continuar sem utilizadores?
Então o horário cumpriu a sua função, que foi eliminar a consistência como explicação. Ao fim de cerca de oito semanas sem respostas, registos ou perguntas, olhe para a oferta, para a definição de audiência e para a própria app antes de acrescentar horas de publicação.