Noite de eleição, 2024. A tela que passamos meses construindo para cobrir a apuração em todo o Brasil apaga — não nossos servidores, não nosso código. Um sistema terceirizado em .NET, rodando numa máquina que entregamos mas nunca tivemos acesso, cede exatamente sob a carga para a qual foi comprado.

Esse é o meio dessa história. A autoridade eleitoral do Brasil — o TSE, Tribunal Superior Eleitoral, o órgão que conduz toda eleição no país e publica os dados brutos por trás dela — e eu já nos encontramos três vezes, e cada vez os dados, e o que eu tinha permissão de fazer com eles, pareciam completamente diferentes.

2019–2020: primeiro contato

As discussões começaram no fim de 2019; fui alocado no projeto no início de 2020, um dev júnior sem ideia do que tinha assinado. A tarefa era ingerir os dados do TSE sobre candidatos e apuração de votos. O que chegou foi uma montanha de arquivos JSON e CSV com a coerência interna de uma sopa de letrinhas.

Documentação existia, tecnicamente. Só que não concordava consigo mesma. Um PDF descrevia um campo que um vídeo mais recente contradizia, e nenhum dos dois batia com as colunas realmente presentes nos dados de simulação que o TSE fornecia — alguns dos campos descritos simplesmente não existiam nos arquivos. Não havia schema em que confiar, só fragmentos para reconciliar. Passei semanas fazendo engenharia reversa de relações entre entidades que nenhum documento explicitava diretamente, dimensionando estruturas a partir de evidência em vez de especificação.

Nunca terminei. Outro desafio surgiu, em logística e entregas, e segui em frente antes do projeto fechar. Eu não sabia ainda, mas o TSE e eu não tínhamos terminado.

2024: a decisão que não era minha para tomar

Nova empresa, novo ciclo eleitoral. A documentação do TSE tinha genuinamente melhorado — os dados simulados eram mais consistentes, a estrutura mais fácil de entender. Dessa vez a necessidade era concreta: integrar dados de candidatos para cobertura pós-eleição, e construir a infraestrutura para consultar a apuração de votos conforme ela chegava.

Argumentei para alocar dois ou três desenvolvedores internos para tocar isso do início ao fim. A empresa optou por um fornecedor terceirizado. Pior decisão que vi ser tomada. O que recebemos foi um sistema em .NET ao qual não tínhamos acesso — não ao código, só ao banco de dados que ele produzia — rodando numa máquina que provisionamos e entregamos. Qualquer mudança, qualquer correção, significava mandar um e-mail e esperar pela boa vontade de outra pessoa para acessar remotamente.

Na noite da eleição, quebrou. No meio do evento, durante a apuração, o sistema do qual dependíamos para uma tela que tínhamos desenhado para cobrir resultados em todo o país simplesmente parou. Aquela tela — sumiu, no exato momento em que importava.

O que salvou a noite foi algo que eu tinha construído por conta própria: publicação automática de artigos de “candidato eleito” em cada município e estado, no momento em que os resultados ficavam finais. A decisão que importou não foi a automação em si — foi atrelar a publicação à flag “eleito” em vez de aos números de apuração ao vivo. Números ao vivo se movem, são corrigidos, são contestados. Uma flag é definitiva. Essa distinção foi a diferença entre publicar algo verdadeiro e publicar algo que eu teria que retratar depois.

Isso gerou uma onda de tráfego de todo o Brasil, cobertura em municípios que ninguém no time editorial conseguiria cobrir manualmente, e recuperou receita real numa noite que de outra forma seria um prejuízo total. Me custou algumas noites tarde e mais xícaras de café do que gostaria de contar. O sistema do fornecedor custou seis dígitos e entregou um blecaute.

2026: dessa vez é diferente

Terceiro encontro. Dessa vez a empresa não hesitou — um time foi alocado, um mandato claro foi dado, e o escopo era meu para tocar: desenho de ETL, modelagem dimensional a partir de dados brutos de apuração, uma API com descoberta de recursos, e templates de conteúdo editorial construídos junto com editores e jornalistas. Duas pessoas, documentação em primeiro lugar, testes desde o dia um. Quando o time de frontend entrou para construir as telas, o backend já estava testado, documentado, e esperando — com um dashboard de telemetria em Prometheus já observando, pronto para o dia do lançamento.

O Claude Code fez parte de como chegamos lá com um time de duas pessoas, e vou entrar em detalhes sobre como isso realmente funcionou nos posts que seguem.

Este post é o contexto. Os próximos dois entram em como foi realmente construído.