Plataforma de Prospecção B2B

O frontend é uma SPA em React 18 sem etapa de build: o JSX é transpilado no navegador e a própria API entrega a página. Escolhi isso para que o deploy fosse um único contêiner, sem pipeline de frontend. O custo aparece no primeiro carregamento, mais lento, e na falta de tipagem e de testes de componente.

A divisão entre os dois bancos segue o dono do dado. O PostgreSQL remoto é compartilhado com outros sistemas e diz o que já existe. O SQLite guarda o que só interessa a esta aplicação, e por isso fica num volume do Docker, fora do contêiner, para sobreviver a um rebuild.

O login é OIDC com PKCE contra o SSO da empresa, com cookie seguro por padrão. Os papéis (usuário e administrador) e os créditos mensais ficam na própria plataforma, porque o SSO diz quem é a pessoa, não o que ela pode gastar. A suíte de testes roda num workflow de CI.

A ordem é fixa. O cache em SQLite responde se tiver um registro com menos de 120 dias. Sem ele, a consulta vai para a API cadastral oficial. Se a oficial falhar, e o administrador permitir, entram três provedores públicos em sequência. A régua (ativa, matriz, porte, fundação há 3 anos ou mais, natureza jurídica que não seja de pessoa física) é aplicada depois da resposta, igual em todas as camadas, para que a escolha do provedor não altere o veredito.

O preço do cache é a defasagem: uma empresa que muda de situação dentro da janela só é vista na próxima ida à fonte. Aceitei isso porque a mesma empresa é consultada muitas vezes por usuários diferentes, e cada consulta à fonte paga latência e limite de requisições.

O Gemini pesquisa o mercado descrito e sugere os códigos de atividade econômica (CNAE). A partir deles a plataforma extrai empresas, passa cada uma pela régua cadastral e remove o que já existe na fonte da verdade. CNAEs secundários entram só se o usuário marcar a opção. A geração roda em segundo plano, e as listas ficam salvas: um reload não perde o trabalho.

Cada usuário tem uma trava contra geração concorrente, então duas gerações dele nunca disputam os mesmos créditos e as mesmas empresas. Quando a geração esgota empresas novas, ela recorre ao resgate e move negócios que já existem no CRM, em vez de criar duplicatas. Esse caminho é best effort: se falhar, a geração entrega o que tem e não cai.

A importação é assíncrona e ganha um id de job assim que começa. As linhas são deduplicadas e enviadas em lotes com throttle, para não estourar o limite de requisições do CRM. Falhas transitórias têm retry com backoff exponencial. O progresso vai para o navegador por SSE.

Tudo que um job criou fica associado ao id dele, e o rollback desfaz só aquele job. O que falhou, e o que foi barrado por já existir na fonte da verdade, pode ser exportado num arquivo para correção e reenvio, em vez de se perder no log.

Quem passa vai para a movimentação em duas fases. A fase A grava a marcação, a plataforma espera um intervalo configurável, e a fase B move o negócio e limpa o responsável. Separei as fases depois de ver o CRM mandar para deduplicação, e apagar, negócios que recebiam marcação e movimentação na mesma escrita.

A chave de idempotência combina execução e negócio. Um negócio preso entre as fases é reconhecido, e a retomada reenvia só a fase B. O crédito é cobrado uma vez por negócio movido, garantido por índice único no livro de créditos. Um limite segue aberto: um dos funis desfaz em silêncio mudanças de categoria feitas pela API, mesmo respondendo sucesso. Daí ficou a regra de tirar um retrato de todos os campos antes de qualquer escrita, para poder reverter com valores lidos e não deduzidos.

Foram extraídos 27,4 mil negócios, dos quais 14,8 mil com rótulo conhecido. O split é temporal, 80/10/10 ordenado por data de criação, porque um split aleatório vazaria o futuro para o treino. Variáveis categóricas usam target encoding com suavização. O desbalanceamento é tratado com scale_pos_weight em vez de SMOTE, a saída passa por calibração isotônica, e cada previsão vem com a explicação do SHAP.

No teste: ROC-AUC de 0,797, PR-AUC de 0,095 e precision@10 de 0,239. O PR-AUC parece baixo, mas a classe positiva é rara, e o número tem que ser lido contra essa taxa base. Um modelo novo só é promovido no registro se ganhar em PR-AUC e mantiver o erro de calibração em até 0,05. Para o concept drift, a janela de treino caiu de 365 para 180 dias, com meia-vida de 60 dias nos pesos.

O enriquecimento cruza os negócios com uma tabela de 71 milhões de linhas. A primeira versão filtrava com ANY() sobre um array de texto e caía em varredura completa. Trocar por um JOIN com unnest deixou a consulta 167× mais rápida.

A primeira versão da busca de empresas similares usava todos os CNAEs da empresa-alvo como semente. Num caso real, um código secundário de transporte bastou para 87,5% dos candidatos serem transportadoras. Hoje a semente é o CNAE principal, expandido pela hierarquia oficial em escopo exato, por grupo ou por setor, e os secundários entram só por opção do usuário.

Buscas amplas batiam no timeout de 120 s por dois motivos: contagens sem filtro de UF e um índice de CNAEs secundários usado mesmo quando não era preciso. Agora o índice só entra quando a busca pede, uma checagem prévia recusa com HTTP 422 o escopo grande demais, e as contagens têm teto curto: acima dele a tela mostra “≥N” em vez de esperar o número exato.

No mapa, a importação por cidade usa a cidade e a UF exatas, sem normalizar grafia, para que o número de créditos bata com o que o mapa mostrou. As abas de análise comercial foram portadas de aplicativos Streamlit de um colega, com conferência numérica contra os originais.