Primeiro vídeo de demonstração e sprint de qualidade: 7 correções críticas

Após 6 meses de desenvolvimento e mais de 700 commits, o TAMSIV tinha tudo: um pipeline de voz funcional, um sistema de gamificação, grupos colaborativos, 6 idiomas suportados. Mas faltava algo essencial — um vídeo. Porque um aplicativo de voz não se descreve. Ele se mostra. Esta semana, gravei o primeiro vídeo de demonstração do TAMSIV e, em paralelo, concluí um sprint de qualidade que corrigiu 7 problemas críticos.

Pontos chave a reter:
- Um vídeo de demonstração é indispensável para um aplicativo de voz — "fale e a IA entende" não é suficiente, é preciso ver o microfone ativando e a tarefa sendo criada.
- Um sprint de qualidade (0 recurso, 7 correções) tem tanto impacto quanto um mês de desenvolvimento quando foca nas fricções diárias.
- O botão de parar de um gravador de voz deve funcionar 100% — mesmo 1% de falha destrói a confiança.
- Sempre esvazie o cache singleton ao fazer logout em um dispositivo compartilhado — um vazamento de dados entre sessões é um bug de segurança crítico.

Por que um vídeo de demonstração é indispensável para um aplicativo de voz?

Por 6 meses, o TAMSIV existiu em texto e capturas de tela. No site, em artigos de blog, nas fichas da Play Store. Mas um aplicativo de voz tem um problema fundamental de comunicação: a interação principal é invisível.

Você pode escrever "fale, a IA entende e organiza" quantas vezes quiser. Enquanto o visitante não vir o microfone ativando, a transcrição em tempo real, a tarefa sendo criada sozinha na pasta certa — ele não entende realmente o que o aplicativo faz.

Como explica Wyzowl em seu relatório de marketing de vídeo de 2026, 96% dos consumidores assistem a um vídeo explicativo antes de comprar um produto ou baixar um aplicativo. Para um aplicativo de voz, esse número é provavelmente ainda maior — o próprio conceito exige uma demonstração visual.

O vídeo agora está visível no YouTube e diretamente integrado no hero do site tamsiv.com. O visitante vê imediatamente como o TAMSIV funciona, sem precisar baixar o aplicativo ou ler uma documentação.

Como integrar um vídeo no hero de um site Next.js?

A integração no site Next.js era óbvia — mas com algumas restrições técnicas:

• Desempenho: sem autoplay, sem pré-carregamento do arquivo de vídeo completo. Um embed do YouTube com fachada (imagem placeholder + botão de play) para evitar carregar o iframe na primeira renderização.
• Responsivo para celular: a proporção 16:9 deve se adaptar sem barras pretas ou transbordamento em todas as telas.
• SEO: tag VideoObject em JSON-LD para que o Google indexe o vídeo e o exiba nos resultados enriquecidos.

O resultado: o hero do site agora mostra uma prévia do vídeo com um botão de play. Um clique carrega o embed do YouTube. É o melhor compromisso entre impacto visual e desempenho — o Largest Contentful Paint não é impactado.

Por que um sprint de 0 recurso muda tudo para a retenção?

Em paralelo ao vídeo, dediquei uma semana a um sprint 100% de qualidade. Nenhum novo recurso — apenas polimento, confiabilidade e correções silenciosas que fazem a diferença no dia a dia. 7 commits. 0 novo recurso.

Isso é contraintuitivo quando você é um desenvolvedor solo. Você tem uma lista de recursos para adicionar tão longa quanto o braço. Cada dia sem um novo recurso parece perdido. Mas é exatamente o contrário: cada micro-fricção removida, cada bug silencioso corrigido, é mais um usuário que não desinstala em 3 dias.

Este sprint segue o sprint de qualidade anterior que já havia corrigido os lembretes e e-mails. Desta vez, as correções afetam o coração do aplicativo.

Como tornar um botão de parar 100% confiável em um gravador de voz?

O bug mais frustrante do aplicativo: às vezes, o botão "parar" não respondia. O microfone continuava gravando, o usuário tinha que forçar a parada. Pesadelo de UX absoluto.

A causa? Um problema de tempo entre a inicialização do STT nativo (reconhecimento de voz do telefone) e o estado do React. Quando o usuário pressionava parar durante uma janela de alguns milissegundos em que o STT estava em transição entre dois estados, o callback de parada era simplesmente ignorado.

A solução técnica em 3 pontos

• Modo "standby" para o STT nativo: em vez de inicializar completamente o STT a cada pressão no botão do microfone, ele permanece em estado de espera ativa. Resultado: inicialização 2x mais rápida, sem espera de callback.
• Botão de parar absoluto: independentemente do estado interno do STT (inicialização, escuta, processamento), o botão de parar aciona uma parada forçada. Sem condição, sem "espere o callback retornar".
• Limpeza de segurança: um timeout de 30 segundos limpa automaticamente qualquer estado residual — inspirado no padrão usado no AudioPlayerService.

Esta correção é talvez a mais importante de todo o sprint. O pipeline de voz é o coração do TAMSIV. Se o botão de gravação não for 100% confiável, nada mais importa.

Como fazer uma IA de voz entender intervalos de datas?

Antes, perguntar "o que eu tenho esta semana?" à IA só funcionava para um dia. O system prompt limitava as solicitações a uma única data. Um problema típico do design de prompts para IA conversacional.

A solução exigiu duas modificações:

1. Extensão do system prompt: adição de exemplos de intervalos de datas ("de segunda a sexta", "os próximos 3 dias", "esta semana") nas instruções da IA.
2. Modificação do function calling: a ferramenta create_calendar_event agora aceita um parâmetro end_date opcional para solicitações que abrangem um intervalo.

Agora, o assistente entende os intervalos: "de segunda a sexta", "os próximos 3 dias", "esta semana". É uma mudança sutil, mas que transforma o uso da agenda no dia a dia.

Por que mudar de SDXL para HiDream para a geração de imagens de IA?

As imagens de capa das pastas no TAMSIV são geradas por IA. Usávamos o SDXL 0.9, que tinha dois problemas principais: ele entendia mal prompts complexos (texto misturado, instruções ignoradas) e a qualidade era inconsistente.

A mudança para HiDream-I1-Fast via Runware mudou tudo. Melhor compreensão do prompt, resultados mais consistentes e um custo de ~0.003 EUR por imagem. É o mesmo modelo que uso para as imagens de IA inline no gravador de voz — a coerência visual é mantida em todo o aplicativo.

Como detectar um vazamento de dados entre sessões de usuário?

Um bug crítico descoberto e corrigido durante este sprint: em um dispositivo compartilhado, os dados do usuário anterior podiam aparecer brevemente durante uma troca de conta. O cache singleton não era esvaziado ao fazer logout.

Este é um bug de segurança de classe crítica. Mesmo que a exposição seja breve (algumas centenas de milissegundos), um usuário pode ver as tarefas, memorandos ou eventos de outro usuário. Em um aplicativo de produtividade que gerencia dados pessoais, isso é inaceitável.

A correção: limpeza completa ao fazer logout

A solução é simples em teoria, mas exige rigor: cada serviço singleton (ContentCacheService, CalendarService, GamificationService) recebeu um método clearAll() chamado sistematicamente a cada desconexão. O sistema de segurança do TAMSIV agora inclui uma verificação de que todos os caches estão vazios antes de inicializar uma nova sessão.

Qual é o impacto combinado do vídeo e do sprint de qualidade?

O vídeo e o sprint de qualidade são duas faces da mesma moeda:

• O vídeo é a vitrine — ele torna o projeto tangível para alguém que nunca tocou no aplicativo. É a ferramenta de aquisição.
• O sprint de qualidade são os fundamentos — ele faz a diferença entre um aplicativo que se experimenta e um aplicativo que se mantém. É a ferramenta de retenção.

Os dois se complementam perfeitamente. Atrair usuários com um belo vídeo para perdê-los por causa de um botão de parar com defeito seria um desastre. Por outro lado, um aplicativo perfeitamente polido que ninguém conhece não serve para nada.

É exatamente a lógica que detalho no artigo sobre o percurso dos mais de 650 commits: cada fase do projeto alterna entre recursos visíveis e polimento invisível.

Que lições tirar para um desenvolvedor solo que lança seu aplicativo?

Depois desta semana, é o que eu retenho:

1. Grave seu vídeo cedo. Não espere que o aplicativo esteja "perfeito". Um vídeo de 2 minutos com um produto funcional vale mais do que meses de descrições textuais.
2. Planeje seus sprints de qualidade. Bloqueie uma semana a cada duas sem nenhum recurso. O sprint zero-feature tornou-se um ritual para mim.
3. O botão principal deve ser infalível. Para o TAMSIV, é o botão do microfone. Para você, é o botão que representa sua proposta de valor principal. Se ele falhar uma vez, você perde a confiança.
4. Verifique a segurança dos singletons ao fazer logout. Se você usa caches em memória em um aplicativo móvel, certifique-se de que eles sejam limpos a cada troca de sessão.

Perguntas frequentes

Quanto tempo leva para gravar um vídeo de demonstração de aplicativo móvel?

Para o TAMSIV, o vídeo de 2 minutos levou cerca de meio dia: preparação do roteiro, 3 tomadas, edição básica. Não é necessário um estúdio profissional — uma boa iluminação e uma tela bem enquadrada são suficientes. O importante é mostrar a interação real, não um mockup.

É necessário um sprint de qualidade antes ou depois do lançamento?

Ambos. Antes do lançamento, um sprint de qualidade visa as fricções mais visíveis (como o botão de parar). Após o lançamento, o feedback dos usuários guia as prioridades. Recomendo um sprint de qualidade a cada 2 semanas durante a fase beta.

O modo standby do STT consome mais bateria?

Não, o modo standby mantém o módulo STT na memória, mas não inicia a escuta ativa. O consumo de bateria é insignificante em comparação com a gravação ativa. É comparável a manter uma conexão SpeechRecognizer inicializada sem iniciá-la.

Como evitar vazamentos de dados entre sessões em um dispositivo compartilhado?

Três regras: (1) cada serviço singleton deve ter um método clearAll(), (2) este método é chamado no handler de logout, (3) um teste automatizado verifica se todos os caches estão vazios após o logout. É básico, mas muitas vezes esquecido em arquiteturas baseadas em singletons.

O HiDream-I1-Fast é melhor que o SDXL para a geração de imagens de aplicativos?

Para imagens de capa e ilustrações contextuais, sim. O HiDream entende melhor prompts complexos e produz resultados mais consistentes. O SDXL continua relevante para fotorrealismo puro, mas para imagens funcionais em um aplicativo móvel, o HiDream é uma escolha melhor com um custo similar (~0.003 EUR/imagem).