App vocal de IA em 650 commits: feedback de um programador solo

Pontos chave: Construir um gerenciador de tarefas por voz com IA sozinho significa mais de 650 commits, um pipeline de áudio em tempo real (Deepgram + OpenRouter + OpenAI TTS), uma arquitetura React Native New Architecture e, acima de tudo, 6 meses de lições sobre o que não fazer. Este artigo aborda a stack completa, os erros caros e as decisões que fizeram a diferença.

Há 6 meses, eu tinha um problema muito simples. Em casa, éramos 4 com pedaços de papel colados na geladeira para as compras. No clube de mergulho, tudo passava pelo WhatsApp — impossível encontrar uma informação de três dias atrás. Os aplicativos existentes? Muito complicados, muitos cliques, não adaptados à vida real.

Hoje, TAMSIV é um aplicativo Android completo com um assistente de voz IA, grupos colaborativos hierárquicos, uma agenda com recorrência, gamificação e fala 6 idiomas. Mais de 650 commits. Desenvolvedor solo. E vou te contar exatamente como cheguei até aqui.

Por que criar um gerenciador de tarefas por voz em 2025?

A resposta curta: porque os aplicativos de produtividade clássicos assumem que você está sentado em frente a uma tela com as duas mãos livres. Mas na vida real, você está dirigindo, cozinhando, passeando com o cachorro ou carregando compras.

Testei dezenas de aplicativos — Todoist, Any.do, Google Tasks, Microsoft To Do. Todos excelentes no papel. Mas nenhum colocava a voz no centro. Eles podiam ter um botão de microfone escondido em algum lugar, mas a interação principal continuava sendo o teclado.

Minha aposta: a voz como interface principal. Você aperta, fala, a IA entende e cria a tarefa. Sem formulários, sem menus suspensos, sem atrito. Se você quiser saber mais sobre por que os aplicativos de produtividade clássicos falham, eu falo sobre isso neste artigo sobre a fadiga dos aplicativos de produtividade.

Qual stack técnica para um aplicativo de voz IA?

Escolher a stack certa é a decisão mais importante. Aqui está o que aprendi depois de 6 meses:

• Frontend: React Native 0.81 (TypeScript) com a New Architecture (Fabric). Desempenho nativo, um único codebase. A escolha se impôs porque conheço React e queria entregar rápido.
• Backend: Node.js/Express + WebSocket. O WebSocket é indispensável para o streaming de áudio em tempo real — HTTP não é suficiente.
• Banco de dados: Supabase PostgreSQL com 3 schemas separados (privat, collaborative, gamification). Explico essa arquitetura em detalhes no meu artigo sobre a estruturação do banco de dados.
• Website: Next.js 16 + Tailwind CSS 4, implantado no Vercel. Contei a construção em 3 dias neste artigo dedicado.

Como funciona o pipeline de voz do aplicativo?

Este é o coração técnico do projeto. O usuário aperta o botão, fala e recebe uma resposta de voz estruturada em 1.5 a 3 segundos. Por baixo do capô:

Áudio PCM 16kHz mono → WebSocket (JWT) → Deepgram STT (VAD) → OpenRouter LLM → Function calling → OpenAI TTS → Resposta de voz

1. Captura de áudio: O telefone envia chunks de áudio brutos em PCM 16 bits, 16kHz, mono via WebSocket.
2. Speech-to-Text: Deepgram transcreve em streaming com detecção automática de fim de fala (VAD).
3. LLM: OpenRouter roteia para mais de 400 modelos com fallback automático. O modelo entende a intenção e usa o function calling para criar tarefas, memorandos ou eventos.
4. Text-to-Speech: OpenAI TTS (voz "nova") gera a resposta de áudio, transmitida de volta via o mesmo WebSocket.

Cada etapa pode falhar independentemente. Implementei retries inteligentes, circuit breakers e fallbacks em cada nível. Para o detalhe técnico completo do pipeline, leia o artigo dedicado ao pipeline de voz.

Quais recursos exigiram mais trabalho?

Em mais de 650 commits, alguns recursos consumiram semanas inteiras. Aqui está o top 3.

Grupos colaborativos hierárquicos

No papel: "adicione grupos". Na realidade: um sistema hierárquico de 6 níveis de profundidade com 4 funções (Admin, Manager, Member, Viewer), consultas recursivas PostgreSQL (CTE) e 31 políticas RLS para escrever e testar individualmente.

Meu clube de mergulho foi o caso de uso perfeito: Clube → Comissão Técnica → Nível 1 → Grupo de terça-feira. A herança de permissões entre os níveis foi o verdadeiro quebra-cabeça. Falo sobre isso em profundidade no artigo sobre grupos hierárquicos.

Agenda com recorrência

Os LLMs não são bons com datas. Quando você diz "todas as terças-feiras às 14h", o modelo deve entender a recorrência, o fuso horário e gerar as ocorrências corretas. Tive que construir uma tabela de correspondência e um sistema de validação robusto. O detalhe técnico está no artigo sobre a agenda e os filtros.

Gamificação

12 níveis, 10 distintivos, sequências de até 365 dias, desafios diários e um placar. Um esquema dedicado com 5 tabelas e gatilhos automáticos. A gamificação não é um gadget — ela muda fundamentalmente o engajamento dos usuários. Detalhei a arquitetura no artigo sobre o esquema de gamificação.

Quais erros evitar ao desenvolver sozinho?

Serei honesto: cometi erros caros. Se você está desenvolvendo um projeto solo, aprenda com meus fracassos.

Erro nº 1: Zero marketing por 6 meses

650 commits e nem um único post para falar sobre isso. Nenhum. Eu estava tão absorto no código que ignorei completamente a parte da visibilidade. No dia em que quis me comunicar, comecei do zero — zero público, zero conteúdo, zero histórico.

A lição: comece o marketing desde o primeiro commit. Mesmo um simples tweet "estou começando um novo projeto" é melhor do que o silêncio.

Erro nº 2: Subestimar a internacionalização

Passar de 100% francês para 6 idiomas (FR, EN, DE, ES, IT, PT) afetou 35 arquivos e 1993 chaves de tradução. É um trabalho enorme quando você faz isso depois. Hoje, cada novo recurso é traduzido desde o início. A i18n se tornou um verdadeiro canal de aquisição — falo sobre isso neste artigo sobre a i18n como alavanca de crescimento.

Erro nº 3: Não estruturar o banco de dados desde o início

Tive a sorte de fazer essa escolha bem, mas vi tantos projetos onde tudo está no esquema public que menciono isso. Três esquemas separados desde o primeiro dia, isso muda tudo para a manutenibilidade. O detalhe está no artigo sobre a reestruturação do banco de dados.

Como gerenciar um projeto solo dessa magnitude?

650 commits em 6 meses, isso dá uma média de 3-4 commits por dia. Alguns dias eu fazia 10, outros zero. Aqui está o que me ajudou:

• Commits atômicos: cada commit faz uma única coisa. Isso torna a depuração e o revert muito mais simples.
• Um monorepo: frontend, backend e website no mesmo repositório. Um único git log para ver o histórico completo do projeto.
• Serviços singleton: ConversationService, CalendarService, GamificationService... cada domínio tem seu serviço dedicado, fácil de testar e manter.
• O padrão PendingCreation: a voz cria uma prévia, o usuário valida, edita ou cancela antes de salvar no banco de dados. Zero surpresas.

Qual é o custo de operação de um aplicativo de voz IA?

Pergunta que todo mundo faz. Aqui está a decomposição por interação de voz:

• STT nativo (dispositivo): gratuito. Deepgram cloud como fallback: ~$0.0059/min.
• LLM via OpenRouter: variável dependendo do modelo, tipicamente $0.001-0.01 por requisição.
• TTS OpenAI: ~$0.015 para 1000 caracteres.
• Supabase: plano gratuito generoso, depois ~$25/mês no Pro.
• Backend Railway: ~$5-10/mês dependendo do uso.

No total, uma interação de voz completa custa entre $0.01 e $0.03. Isso é viável com um modelo freemium — detalhei os níveis de assinatura no artigo sobre RevenueCat e as assinaturas.

Onde o projeto está hoje?

TAMSIV está em alfa na Google Play Store. 12 testadores ativos. O lançamento em produção pública é iminente.

As métricas que importam:

• Mais de 650 commits no monorepo
• 6 idiomas suportados (FR, EN, DE, ES, IT, PT)
• 3 modos WebSocket (Live, Realtime, Batch)
• 31 políticas RLS para a segurança dos dados
• 12 níveis de gamificação com distintivos e sequências
• 6 abas: Gravador, Feed, Agenda, Grupos, Social, Perfil

FAQ

Quanto tempo leva para construir um aplicativo de voz IA sozinho?

Para TAMSIV, levou 6 meses em tempo integral. O pipeline de voz sozinho (STT + LLM + TTS) levou cerca de 3 semanas. Os grupos colaborativos e a gamificação adicionaram 2 meses cada. Se você se concentrar apenas no MVP de voz, conte 2-3 meses.

Por que React Native em vez de Flutter ou nativo?

Eu já conhecia React. A New Architecture (Fabric) do React Native 0.81 oferece desempenho quase nativo. Flutter era uma opção válida, mas o ecossistema npm e a comunidade React inclinaram a balança. O nativo puro teria dobrado o tempo de desenvolvimento sem vantagem significativa para este tipo de aplicativo.

O Speech-to-Text nativo é tão bom quanto o Deepgram?

Para a maioria dos casos, o STT nativo do dispositivo é suficiente e gratuito. Deepgram se destaca em ambientes ruidosos e para idiomas não europeus. TAMSIV usa o nativo por padrão e alterna para Deepgram como fallback. Comparei os dois em detalhes no artigo STT nativo vs Deepgram.

Como monetizar um aplicativo de voz IA sem explodir os custos?

O modelo freemium com limites diários no plano gratuito. Os recursos caros (STT cloud, geração de imagens IA) são reservados para os planos Pro e Team. RevenueCat gerencia as assinaturas in-app. O segredo é otimizar o custo por interação — o STT nativo gratuito cobre 90% dos usos.

É necessário um backend para um aplicativo de voz ou tudo pode rodar localmente?

Você precisa de um backend para o LLM (function calling, orquestração) e o TTS (as APIs estão no lado do servidor). O STT pode rodar localmente. O WebSocket é indispensável para o streaming em tempo real — as chamadas HTTP clássicas adicionam muita latência.