Eu trabalhava CLT em paralelo e procurava um problema que valesse fundar uma empresa em volta. Comecei conversando com motoristas de app em viagens a trabalho - novatos, veteranos, todos - e a mesma dor voltava: nenhum tinha clareza se estava de fato lucrando. Aceitavam a corrida que pagava mais no momento e descobriam no fim do mês que não fecharam o custo fixo. A Batameta começou aí: uma ferramenta que calcula a meta diária que o motorista precisa bater pra pagar as contas reais dele no dia certo, mais um Copilot nativo que classifica cada oferta de corrida do Uber/99 no segundo em que chega. Construir isso me levou pra terreno que eu não tinha trilhado antes - bridge nativo no Android pra ler telas que não controlamos, telemetria anonimizada pra validar parser em dispositivos que eu nunca vou ter, arquitetura Open/Closed pra que o próximo app de corrida entre sem reescrita. Hoje 4 apps estão no ar, motoristas usando todo dia, e estou aprendendo que ser fundador significa que a engenharia é a metade fácil.
O problema que pegamos
Conversando com motoristas, a mesma cena se repetia. O motorista tem uma conta de R$ 800 que vence no dia 8 e tenta se planejar dividindo o valor pelos dias restantes do mês - mas a conta tá errada, a jornada diária não bate e a fatura escorrega. Multiplica isso por custos recorrentes (aluguel, seguro, combustível) e alguns choques não-recorrentes (um pneu, uma revisão), e a maioria dos motoristas não consegue dizer se fechou o custo na semana.
Engine de metas
Meta mensal = recorrente + não-recorrente + lucro desejado + contas postergadas de meses anteriores. Meta diária = (mensal − já ganho) ÷ dias úteis restantes, considerando a data de vencimento real de cada conta e o padrão de jornada que o motorista escolheu. Quando bate a mensal, entra uma extra-diária baseada na própria média de ganho. Cada recálculo chega como push: 'sua meta hoje é R$ X' - todo o modelo financeiro vira um número no pulso do motorista antes dele ficar online.
Desafio: ler apps que não controlamos
O Copilot precisa ler cada oferta do Uber/99 no momento em que ela aparece, em tempo real, no celular do motorista - e a gente não controla esses apps. Não dá pra entrar com código, não tem API pública, e a gente não quer screenshot saindo do device por questão de privacidade e custo.
Solução: bridge nativo no Android
Construí um módulo nativo em Kotlin que o React Native chama. Um AccessibilityService observa Uber/99 em foreground, atravessa a view tree e cai pra OCR via ML Kit quando a árvore está bloqueada. Parsers por app (UberParser, NinetyNineParser) extraem preço, distância, tempo, embarque, destino e nota. A avaliação roda 100% no device contra o perfil de custos do motorista em cache. A API só serve config de parser (cache de 1h) - zero chamadas por corrida significa privacidade preservada e Copilot funcionando até em conexão ruim.
Desafio: confiar no parser em aparelhos que eu nunca vou ter
Eu testo no meu aparelho. Os usuários têm milhares de outros - versões de Android diferentes, fabricantes diferentes, alterações específicas de cada OEM na view tree. Como saber se o parser tá pegando certo lá fora?
Solução: pipeline de telemetria anonimizada
Toda vez que uma oferta entra no Copilot, com consentimento explícito do usuário, o device manda um payload mínimo: o dado bruto extraído da tela, a saída parseada, versão do app, versão do módulo do Copilot, versão do Android, fabricante, endereço de embarque/destino bruto e parseado. Totalmente anonimizado - a gente não tem como mapear um payload de volta pra um usuário. Comparar bruto vs parseado em escala mostra exatamente em quais aparelhos o parser está falhando e onde ele precisa endurecer. O Copilot fica melhor quanto mais é usado.
Desafio: todo app de corrida muda a UI sem avisar
Uber atualiza um layout. 99 manda um redesign. iFood e InDrive não se parecem em nada. Hard-codar parser contra a view tree de hoje significa quebra em uma semana.
Solução: arquitetura Open/Closed + parser hot-swap
O core do Copilot é fechado - não sabe nada de app específico. Cada integração entra como parser implementando um único contrato. Config de parser vem da API e atualiza de hora em hora, então quebra de UI corrige sem release de app. Adicionar um app novo (iFood, InDrive, futuros) é parser plugando, nunca rewrite.
Plataforma de backend
NestJS event-driven + Prisma sobre PostgreSQL com 7 schemas isolados (customers, marketing, goals, finances, admin, payments, public) - bounded contexts com fronteira clara de ownership. RabbitMQ desacopla trabalho async, MongoDB guarda logs de evento de alta escrita, OpenAI cuida de enriquecimento de endereço ambíguo em fila separada. Pagamento é agnóstico por design: Stripe pra cartão, AbacatePay pra PIX nativo BR (cobrança + recorrência + webhooks). Os dois rails são idempotentes, reconciliação igual independente do provedor. Ativação orquestra push Expo, WhatsApp (WAHA), React Email + Resend, mais engine de referral/reward e módulo de gamification (badges, níveis, streaks).
O que estou aprendendo como fundador
A engenharia é a metade fácil. A metade difícil é conexão, conversa e botar o produto na frente das pessoas. Hoje tenho um sócio que toca marketing e growth - o inverso do meu perfil - e a lição que se repete é que produto não é o mais bonito da tela, é o mais fácil de usar que resolve uma demanda real. O cliente é quem decide o que é bom. Meu trabalho como CEO/CTO é traduzir isso em tecnologia.
- Por que Copilot nativo Android em vez de notificações in-app?AccessibilityService em Kotlin + OCR via ML KitAvaliador de oferta precisa ler a tela do Uber/99 no momento que ela aparece sem modificar os apps deles e sem screenshot saindo do device. AccessibilityService é o único caminho. Avaliação 100% local mantém privado e zera custo de API por corrida.
- Por que pagamento dual-rail (Stripe + AbacatePay)?Stripe + AbacatePayStripe é o rail internacional fácil de cartão, mas PIX domina BR e PIX recorrente pelo AbacatePay é dramaticamente mais barato que cartão pra persona motorista. Os dois rails rodam webhook-driven com idempotência, então reconciliação é idêntica.
- Por que PostgreSQL multi-schema (7 schemas) em vez de schema único?Schema por bounded-contextCustomers, marketing, goals, finances, admin, payments e public moram em schemas próprios. Bounded contexts ganham fronteira clara de ownership; backup, migration e até roles de acesso por domínio ficam simples. Adicionar domínio é operação de schema, não rearquitetura.
- Por que config de parser server-side, avaliação client-side?Parser hot-swappable, avaliação localUber/99 mudam UI sem avisar. Puxar config de parser da API significa que corrigimos sem release de app. Mas avaliação fica local pra dado do usuário não sair do device e não pagar custo de rate-limit por corrida.
- Por que telemetria opt-in com bruto + parseado?Payload anônimo, bruto junto do parseadoNão dá pra validar qualidade do parser contra um ecossistema Android inteiro a partir de um único celular. Mandar o dado bruto da tela junto do parseado - anonimizado e com consentimento - mostra em escala onde o parsing diverge, em que versão do Android, fabricante e build do app. O Copilot melhora quanto mais é usado, em vez de degradar a cada layout novo do vendor.
De ideia a fintech operacional: 4 apps no ar, motoristas usando todo dia, assinantes pagantes e tração inicial (foco agora em retenção). Copilot nativo na mão dos usuários, pagamento dual-rail agnóstico processando, ~76 specs guardando o código, arquitetura Open/Closed pronta pro próximo app de corrida plugar.