Sprint zero feature: 30 commits de polish antes do lançamento

O polimento é mais lucrativo do que as funcionalidades. Em 48 horas e 30 commits sem nenhuma funcionalidade nova, tornei meu aplicativo mais sólido do que em seis meses de adições. Eis por que um sprint "zero funcionalidade" antes de um lançamento é a melhor decisão que um desenvolvedor solo pode tomar.

Por que fazer um sprint sem funcionalidades antes do lançamento?

Durante seis meses, cada dia de desenvolvimento adicionava algo. Uma funcionalidade, uma tela, um pipeline, uma integração. O contador de commits subia, os arquivos se acumulavam, e o aplicativo crescia ao longo dos mais de 650 commits.

E então chega um momento em que é preciso parar. Não por cansaço, mas por lucidez. O aplicativo funciona para 12 testadores alfa que conhecem seus limites. Mas o público em geral não perdoa. De acordo com um estudo da Apptentive, 77% dos usuários leem pelo menos uma avaliação antes de baixar um aplicativo. E um único bug visível no momento errado é uma avaliação de 1 estrela.

Esta semana, fiz o oposto de tudo o que havia feito até então: 30 commits em 48 horas. Zero funcionalidades. Apenas polimento, correções e preparação para o momento em que o aplicativo sai do alfa e entra no mundo real.

Como corrigir 15 bugs em uma única tela de personalização de IA?

A IA do TAMSIV permite que os usuários se apresentem por voz. Tu pressionas, contas a tua vida em 30 segundos, e o assistente se adapta à tua personalidade. O problema: a tela de configuração tinha 15 bugs sutis que os testes automáticos não detectavam.

Um botão escondido por uma sobreposição. Um texto truncado em telas pequenas. Um loop infinito quando o usuário interrompia a IA no meio de uma resposta. O prompt que se reiniciava após cada modificação. Os botões de ação empilhados uns sobre os outros em vez de se posicionarem verticalmente.

Nenhum desses bugs teria sido encontrado em um teste rápido. Era preciso usar o aplicativo como um usuário real — pressionar em todos os lugares, interromper no momento errado, voltar, tentar novamente. É o que o Nielsen Norman Group chama de teste de usabilidade exploratório: sem script, apenas um humano tentando quebrar a interface.

15 commits para tornar uma única tela confiável. Parece excessivo. Mas quando é a tela que define como a IA te entende, cada micro-bug degrada a experiência inteira.

Qual é a diferença entre "funciona em alfa" e "está pronto para produção"?

O sistema de assinaturas Free/Pro/Team existia desde fevereiro. Funcionava em alfa. Mas "funcionar em alfa" e "estar pronto para produção" são duas coisas muito diferentes.

Em alfa, 12 testadores sabem que é um trabalho em andamento. Eles aceitam uma redação aproximada, um design não totalmente ajustado, limites nebulosos entre os planos. Em produção, cada ambiguidade custa um usuário. De acordo com a ProfitWell, uma página de preços confusa pode reduzir as conversões em 20 a 40%.

A reformulação abordou três eixos:

• A redação: cada texto foi relido para esclarecer o que é gratuito versus pago. Sem mais formulações ambíguas.
• O design do modal alfa: ele não tem mais razão de existir em produção. Removido e substituído por um fluxo natural para os planos RevenueCat.
• Os limites do plano gratuito: cada tela verificada em 3 tamanhos de tela diferentes, cada texto responsivo.

O tipo de trabalho que não aparece em um changelog, mas que faz a diferença entre um usuário que entende o que está pagando e um usuário que desinstala por confusão.

Quais "pequenos detalhes" têm o maior impacto na retenção?

Três ajustes menores transformaram a experiência diária do aplicativo.

O botão de parar TTS. Quando a IA te responde em voz alta e tu queres pará-la, antes era preciso cortar o som do telefone. Agora, um simples alternador é suficiente. Parece inofensivo, mas é exatamente o tipo de atrito que leva um usuário a desinstalar. O ditafone é o coração do TAMSIV — ele deve ser impecável.

O escopo estrito do LLM. A IA tendia a responder a perguntas fora do tópico — clima, cultura geral, filosofia. Em produção, ela deve permanecer focada: tarefas, memorandos, eventos. Ponto. Um guarda-chuva de backend que recusa educadamente todo o resto. Como explica o guia de engenharia de prompt da OpenAI, definir limites claros para o LLM é essencial para uma experiência de usuário consistente.

O alternador de imagens geradas. Cada conversa pode gerar uma imagem de capa via IA, graças à integração Runware no ditafone. Mas isso custa créditos. Um switch no cabeçalho do ditafone agora permite desativar a geração de imagens em tempo real. Transparência e controle.

O que o versionCode 30 representa para um desenvolvedor solo?

Cada build Android tem um número. Estamos no 30º. Os 29 anteriores eram alfa — builds para 12 testadores que aceitavam os bugs em troca da primazia. A build 30 é a última antes que qualquer pessoa possa baixar o TAMSIV na Play Store.

É um número banal. Mas ele representa o momento em que "meu aplicativo" se torna "um aplicativo". Onde o código não é mais protegido pelo filtro benevolente dos beta-testers. Onde cada bug é uma potencial avaliação de 1 estrela.

Para colocar isso em perspectiva: o sprint de qualidade anterior já havia corrigido dezenas de problemas. A build 30 é o culminar de duas semanas de polimento intensivo, não apenas de 48 horas. É a camada final antes da produção.

Como decidir quando parar de adicionar funcionalidades?

A tentação do desenvolvedor solo é adicionar sempre mais. Uma funcionalidade chama outra. O backlog nunca se esvazia. E quanto mais o aplicativo cresce, mais cada adição cria interações imprevistas com o resto.

Apliquei uma regra simples: se um bug pode ser encontrado nos primeiros 5 minutos de uso, ele é prioritário sobre qualquer funcionalidade do backlog. É o que Marty Cagan chama de "teste do cliente de referência" — se o teu usuário de referência não consegue concluir o percurso básico sem atrito, nada mais importa.

Este sprint me ensinou algo: o polimento não é inimigo do progresso. É o contrário. Corrigir 15 bugs em uma única tela tornou o aplicativo mais sólido do que qualquer nova funcionalidade. Os usuários não veem os commits. Eles veem um aplicativo que funciona — ou que não funciona.

Qual é o fluxo de trabalho de um sprint de polimento na prática?

Concretamente, foi assim que organizei estas 48 horas:

1. Auditoria por tela: abri cada tela do aplicativo em 3 dispositivos diferentes (pequeno, médio, grande) e anotei cada anomalia visual ou funcional.
2. Priorização por impacto: os bugs visíveis nos primeiros 5 minutos no topo, os casos de uso extremos na parte inferior.
3. Commits atômicos: um commit = uma correção. Sem commits genéricos. Isso permite reverter cirurgicamente se uma correção quebrar outra coisa.
4. Teste de regressão: após cada correção, reverificação das telas adjacentes. Quando tu tocas na arquitetura de um componente compartilhado, o efeito dominó é real.

Este fluxo de trabalho não é espetacular. Não há nova tecnologia, nem refatoração heroica. Apenas disciplina e tempo gasto usando o próprio aplicativo como um usuário comum.

Por que o polimento é mais lucrativo do que as funcionalidades para um lançamento?

Os números são claros. Na Play Store, aplicativos com classificação inferior a 4 estrelas perdem até 50% de seus downloads potenciais. E as primeiras avaliações são decisivas: elas definem a trajetória do aplicativo para os meses seguintes.

Adicionar uma funcionalidade que impressiona 10% dos usuários, mas que cria um bug para 5% deles, é uma troca ruim. Por outro lado, corrigir 30 micro-bugs que potencialmente afetam a todos é um investimento com retorno garantido.

Este sprint de polimento tocou todo o percurso do usuário: desde o onboarding até a gestão de assinaturas, passando pelo coração do aplicativo — o ditafone de voz. E a diferença está nesses 30 commits invisíveis.

A build 30 está pronta. O aplicativo está mais limpo, mais estável, mais claro do que nunca. O próximo passo é o público em geral.