Como publicar um app na Play Store sem perder 14 dias esperando

Quem abre conta pessoal de desenvolvedor no Google Play não vai direto para produção. Antes disso vem um teste fechado, com um número mínimo de testadores e um prazo em dias. O detalhe que muda o cronograma é que esse prazo não depende de o app estar pronto, e sim de gente com o app instalado. Dá para começar a contar cedo e construir o resto enquanto os dias correm.

Martin chegou nessa conta enquanto o Fumava, o app dele para ajudar quem quer parar de fumar, ainda estava preso nas telas de onboarding. Ele parou a construção no meio, disse que queria debater o plano antes de mandar escrever qualquer código, e pediu ao agente que fosse ler a documentação da loja.

A conta pessoal foi quem trouxe o teste fechado

A exigência é herança de uma decisão anterior. Quando ele foi criar a conta de desenvolvedor no Google Play, terminou com uma conta pessoal. É a conta pessoal que obriga a passar pelo teste fechado antes de pedir acesso à produção, de modo que a escolha que destravou o cadastro reapareceu semanas depois dentro do cronograma.

"Confirmei na documentação"

"Confirmei na documentação. A conta pessoal depois preciso no mínimo 12 testadores [opt-in] por 14 dias [...] antes de pedir acesso à produção."

Sabendo do prazo, Martin fez a pergunta que decide o resto do planejamento:

"eu até queria saber se a pessoa precisa usar ou é só instalar mesmo"

O agente voltou com a leitura completa:

"mecanicamente aceitar o convite e instalar com a conta Google que recebeu o convite. Convidado que não instalou não conta. O Google não publica nenhuma métrica de uso mínimo. A documentação só diz que você deve encorajar a usar [...]. Não existe [limiar] de sessões ou de minutos. Então, na prática, instalar e permanecer [opt-in] é o que move o contador."

Nenhuma das partes dessa resposta vale sozinha. A documentação, segundo o que o agente leu, pede que você encoraje o uso real do app pelos testadores. O que ela não estabelece é um número medido de sessões ou de minutos. Isso tudo é regra de loja de terceiro, lida por um agente em 4 de agosto de 2026: quantidade de testadores, prazo e critérios mudam sem aviso, e quem for fazer deve conferir a documentação atual antes de montar cronograma em cima destes números.

Instalar move o contador, e mesmo assim isso não é um plano

Um testador que aceita o convite, instala e nunca abre o app cumpre o requisito mecânico sem devolver a única coisa que o teste existe para dar, que é defeito encontrado antes do público. Quem trata a etapa como carimbo chega na produção com exatamente o app que tinha 14 dias antes, e perde a rodada de feedback mais barata do projeto inteiro, aquela em que o erro chega por mensagem no WhatsApp em vez de avaliação na loja.

Martin vai recrutar entre conhecidos, e disse na live que pretende juntar mais gente do que o mínimo. O agente levantou uma ressalva sobre esses conhecidos não serem fumantes, e a transcrição corta antes de dizer qual era. O raciocínio a seguir é meu, não dele: quem está fora do público-alvo instala, abre uma vez e não tem motivo para voltar no terceiro dia, e é no terceiro dia que aparece a notificação que chega na hora errada ou a conta de economia que não bate. Um fumante que quer parar usa o app com a expectativa de quem precisa dele; o amigo que não fuma está fazendo um favor, e favor não produz relatório de bug.

O relógio dos 14 dias não espera o vibe coding terminar

Na live o raciocínio ficou assim: se o teste fechado só precisa de gente com o app instalado, empilhar semanas de desenvolvimento antes de abrir o período joga 14 dias para o fim do cronograma sem nenhum ganho. Subir agora uma build gratuita, ainda incompleta, faz esses 14 dias correrem em paralelo com o desenvolvimento do que falta, em vez de esperarem a vez deles no fim da fila.

Junto veio uma decisão de produto que caiu bem. Durante o teste o app precisa estar livre de cobrança, porque ele vai pedir para conhecidos instalarem e não vai cobrar de amigo. Martin já tinha visto que os apps concorrentes empurram o usuário do onboarding direto para o paywall, e estava em dúvida se colocaria alguns dias de teste grátis. Ele adiou: a decisão sobre cobrança só existe quando existir paywall, e não trava o começo dos 14 dias. No vibe coding sai barato adiar uma decisão que ainda não tem consequência, já que refazer a tela depois custa menos do que os dias parados custariam agora. Foi o mesmo caminho de rate limit na raspagem no vibe coding. Isso aparece também em vibe coding para não ficar preso na pesquisa. Foi o mesmo caminho de disciplina e constancia. Foi o mesmo caminho de vibe coding para recusar rotulo sem citacao na peca. Isso aparece também em vibe coding para acesso a producao na play store. Isso aparece também em como colocar um app na play store. Vale ver como isso terminou em como sacar dinheiro da play store. Isso aparece também em como ganhar dinheiro com app na play store. Isso aparece também em como fazer um aplicativo. Vale ver como isso terminou em como publicar app na apple store. Vale ver como isso terminou em owasp o que é.

Comece o cronômetro antes de terminar o app

Confira hoje, na documentação atual da loja, quantos testadores e quantos dias o teste fechado está exigindo. Depois monte a build mais magra que abre e não cobra, suba no teste fechado e mande os convites antes de o produto estar pronto. Recrute mais gente do que o mínimo, contando com quem aceita e some. Escolha, entre os convidados, os que têm motivo real para abrir o app numa terça de manhã, e peça a eles o que o contador não pede: que usem e digam o que quebrou. O resto do vibe coding continua rodando enquanto os dias passam. A conversa inteira, incluindo a parte em que ele decide adiar o trial, está na live do Fumava.