projetos/01 · produção

JVB — ERP jurídico sob medida

Do WhatsApp na planilha ao sistema único: captação, processos, prazos, petições, financeiro e IA num só produto, em produção e em uso diário.

Ano
2026 · em produção
Papel
Desenvolvedor único: produto, arquitetura, back, front e infra
Stack
TypeScript · React 19 · tRPC · Drizzle · PostgreSQL · Railway
Link
sistema privado do cliente
painel do dia · o sistema inteiro numa tela passe o cursor para ver em cor

O problema

Um escritório de advocacia de pequeno porte operava como opera quase todo escritório pequeno: planilha para os processos, WhatsApp para o atendimento, e-mail para os prazos e um SaaS jurídico genérico para o resto. A mesma informação era digitada em quatro lugares, prazo aparecia tarde, lead sumia no meio da conversa pessoal, e ninguém respondia rápido a "como está o processo do fulano?".

O problema não era falta de ferramenta. Era que nenhuma ferramenta conhecia o fluxo do escritório — lead chega pelo WhatsApp, vira cliente, vira processo, gera prazo, audiência, petição e honorário. Cada software cobria um pedaço; nenhum cobria a costura entre eles.

A decisão

Construir um sistema só, com banco só e login só, que seguisse o funil inteiro em vez de mais uma ilha. tRPC com Zod para o tipo ser compartilhado entre cliente e servidor: renomear um campo quebra o build, não a produção. Drizzle para ter SQL de verdade quando o domínio pede. Railway com uma réplica só, porque escala especulativa em escritório de cinco pessoas é custo, não virtude.

E uma camada própria de IA multi-provedor, para que trocar de modelo fosse configuração e não decisão de arquitetura.

A escala

O sistema cobre captação, processos, prazos e audiências, petições, inteligência sobre diários oficiais, financeiro e gestão de permissões — com auditoria de ações, 2FA e cofre de credenciais. Tudo construído, mantido e suportado por uma pessoa.

124tabelas no Postgres
881procedures tRPC
3.500+testes automatizados
1desenvolvedor

Contar prazo é mais difícil do que parece

O CPC conta prazo em dias úteis (art. 219), exclui o dia do começo (art. 224), prorroga vencimento em dia não útil (art. 224, §1º) e suspende tudo no recesso forense de 20/12 a 20/01 (art. 220). "Dia útil" ainda inclui feriado móvel derivado da Páscoa, feriado forense e feriado específico de cada tribunal.

Escrevi um motor puro, sem biblioteca de calendário, com toda a aritmética em UTC ao meio-dia para eliminar bug de fuso e horário de verão — Páscoa pelo algoritmo de Meeus/Jones/Butcher, cada regra coberta por teste. É o código mais testado do sistema: ninguém elogia código que conta feriado, mas se ele erra um dia o cliente perde o processo.

O healthcheck que envenenou o banco

Um incidente real. O sistema aprendia a própria URL pública a partir do primeiro request depois do deploy — e o primeiro request depois do deploy é o healthcheck da plataforma, com um Host que não resolve publicamente. Resultado: links de anexo gravados apontando para um host que não existe.

O diagnóstico saiu do sintoma ("anexo não abre") até a causa raiz, e a correção foi um guard na origem mais um reparo idempotente no boot para os dados já gravados. Bug de infraestrutura fantasiado de bug de produto.

Fazer menos, de propósito

Todo adiamento do projeto tem gatilho escrito: virtualizar a lista de mensagens só acima de ~1.500 mensagens, mover mídia para bucket só quando o volume justificar. Um escritório de cinco pessoas não paga a conta de arquitetura de SaaS, e o maior risco de um desenvolvedor único é construir para um problema que nunca chega.

É o que eu levo daqui: foi o primeiro projeto em que fui produto e engenharia ao mesmo tempo, com usuário real do outro lado que perde dinheiro se eu errar. A decisão mais cara de um dev sozinho não é escolher a stack — é escolher o que não construir. E traduzir um domínio complexo, o CPC, o processo eletrônico, a rotina do escritório, é metade do trabalho.