Voltar para Cases
Jurídico

Juscia

CRM jurídico para advogados, com atendimento via IA, análise de casos e processos e acompanhamento em tempo real.

Ver onlineFalar sobre esse case
A virada

Juscia: o antes e o depois

A Juscia chegou até a Bootcom depois de dois anos com uma equipe interna que nunca conseguiu estabilizar o produto. Entramos, auditamos o que existia, reescrevemos a base da aplicação e, em um mês, entregamos o que a equipe anterior dizia não ser possível. É a consultoria da Bootcom na prática: encontrar falhas, arquitetura ruim e código ruim, e corrigir. Os números abaixo foram apurados no próprio repositório do projeto.

1 mês

Para estabilizar o que 2 anos de equipe anterior não conseguiram.

< 1 semana

Para entregar dois recursos que a equipe anterior dizia serem impossíveis.

< 10%

Era a satisfação dos usuários antes da Bootcom assumir o projeto.

24

Falhas graves de segurança corrigidas, da senha universal a brechas de acesso entre escritórios.

Arquitetura, antes e depois

Tudo numa única VM, sem separação de serviços
Infraestrutura na Google Cloud, com serviços dedicados
6 processos em produção: a API e mais 5 serviços auxiliares em Python
1 processo em produção, com as filas rodando dentro da própria API
Agendamento e follow-up disparados por chamada HTTP sem retentativa
Jobs persistentes em fila Redis, com 3 retentativas automáticas
Esquema do banco sincronizado automaticamente em produção
77 migrações versionadas no controle do banco
Uma senha universal com acesso a qualquer conta do sistema
Senha temporária de 30 min, sob demanda, guardada só como hash
CORS liberado para qualquer origem e sem cabeçalhos de segurança
CORS restrito às origens conhecidas e cabeçalhos de segurança aplicados
Nenhum painel de controle pra equipe
Painel de controle completo, com 13 telas
Infraestrutura sem nenhuma capacidade de escalar
Arquitetura pronta pra escalar horizontalmente
28 pontos

O que encontramos

Tudo numa única VM
API e serviços auxiliares dividiam a mesma máquina virtual, sem separação, sem redundância e sem capacidade de escalar. Qualquer pico de uso ou falha atingia o sistema inteiro de uma vez.
Seis processos rodando em paralelo
Além da API, mais cinco serviços auxiliares escritos em Python ficavam no ar o tempo todo, na mesma máquina, cada um com a própria porta e o próprio ciclo de vida pra alguém acompanhar.
Follow-up e agendamento sumiam em silêncio
O disparo dependia de uma chamada HTTP direta pra esses serviços auxiliares. Se o processo estivesse fora do ar ou reiniciando, a falha era engolida: não havia retentativa, não havia alerta, e o follow-up simplesmente desaparecia sem ninguém ficar sabendo.
Treze falhas de acesso entre escritórios
Um usuário autenticado de um escritório conseguia ler, editar ou apagar dados de outro escritório apenas trocando um identificador numérico na requisição. Eram treze pontos diferentes do sistema, da transferência de conversa aos quadros de kanban.
Rotas sem autenticação e uma injeção de SQL
Cinco endpoints respondiam a qualquer um que os chamasse, sem exigir login, um deles devolvendo a lista completa de usuários com e-mail. Uma rota de contagem também tinha uma injeção de SQL, por montar a consulta concatenando texto.
Webhooks abertos
Os webhooks aceitavam qualquer chamada, sem validar a origem. Na prática, dava pra forjar um evento de entrada e fazer o sistema reagir a algo que nunca aconteceu.
Credenciais escritas no código
Chaves de serviços externos estavam fixas no código-fonte. Quem tivesse acesso ao repositório, ou ao histórico dele, tinha as credenciais junto.
CORS liberado e sem cabeçalhos de segurança
A API aceitava requisição de qualquer origem e não enviava nenhum dos cabeçalhos de segurança que o navegador usa pra proteger o usuário.
Uma senha universal abria qualquer conta
Existia uma senha única que dava acesso a qualquer conta do sistema, prática que a equipe anterior considerava aceitável.
Token de autenticação no localStorage
O token ficava guardado no armazenamento local do navegador, de onde qualquer script rodando na página consegue lê-lo.
Dados pessoais nos rastros de telemetria
Telefone, nome e conteúdo de mensagem do WhatsApp eram gravados nos rastros de monitoramento da aplicação, sem nenhuma anonimização, fora de conformidade com a LGPD.
Banco sincronizado automaticamente em produção
O ORM alterava o esquema do banco sozinho a cada subida, sem migração versionada. O que existia eram dez arquivos SQL soltos, sem controle de ordem e sem histórico confiável do que já tinha sido aplicado.
IDs sequenciais e fáceis de adivinhar
As tabelas centrais do banco usavam identificador numérico sequencial, o tipo de chave que facilita adivinhar o próximo registro só somando um ao anterior, exatamente o que abria as falhas de acesso entre escritórios.
Oito arquivos de teste no projeto inteiro
O back-end inteiro tinha oito arquivos de teste automatizado. Na prática, quase toda mudança dependia de teste manual pra não quebrar alguma coisa.
Serviços gigantes, difíceis de manter
Alguns serviços chegavam a mais de 1.800 linhas de código numa função só, o que tornava qualquer mudança arriscada e praticamente impossível de testar em partes.
Consultas N+1 nos relatórios
Relatórios, dashboard e kanban faziam uma consulta ao banco pra cada item da lista, em vez de uma consulta só trazendo tudo de uma vez. Quanto mais dado, mais lenta ficava a tela.
Relatório de vendas somava o escritório inteiro
O número de vendas mostrado pra um atendente era, na prática, a soma do escritório inteiro, não o total individual dele.
Uma falha derrubava o servidor inteiro
Um erro no envio de uma única mensagem não ficava contido: derrubava o processo e, com ele, o sistema todo.
Deploy manual aos domingos, sem esteira de integração contínua
Publicar uma versão era procedimento manual, só feito na madrugada de domingo pra reduzir o risco de atrapalhar quem estava usando. Não havia verificação automática a cada mudança: as checagens de qualidade existiam apenas num gancho local de commit, que qualquer pessoa podia pular.
Interface difícil até pro básico
A interface era pouco funcional a ponto de tarefa simples do dia a dia virar obstáculo.
Bot e CRM sem funcionar
O bot de atendimento respondia errado quando respondia, e o CRM estava praticamente fora de uso.
Paleta de gráficos ilegível pra quem tem daltonismo
As cores usadas nos gráficos ficavam praticamente indistinguíveis pra quem tem os tipos mais comuns de daltonismo, sem nenhuma validação de contraste entre elas.
Cinquenta e seis erros de acessibilidade no front-end
O front-end tinha 56 problemas de acessibilidade identificados, do tipo que dificulta o uso por quem depende de leitor de tela ou navegação por teclado.
Dois anos sem uma versão estável
O projeto rodava havia dois anos e nunca tinha chegado a uma versão que a própria equipe considerasse estável em produção.
Nenhum painel de controle
A equipe da Juscia não tinha nenhuma tela administrativa. Qualquer ação de gestão precisava ser feita direto no banco de dados.
Satisfação abaixo de 10%
Menos de um em cada dez usuários se dizia satisfeito com a plataforma.
Infraestrutura cobrando pelo que ninguém usava
O custo não tinha relação com o tamanho da base de usuários. Havia revisões antigas do serviço esquecidas no ar, sendo cobradas todo mês sem atender ninguém.
Código sem padrão nenhum entre as partes do sistema
Cada parte do sistema seguia uma convenção diferente de código e de arquitetura, sem nada documentado pra próxima pessoa seguir.
28 pontos

O que fizemos

Infraestrutura reconstruída na Google Cloud
Banco, cache e armazenamento passaram a rodar em serviços dedicados, cada um configurado e protegido por conta própria, no lugar de tudo dividindo a mesma máquina.
Os cinco serviços em Python saíram do ar
Foram substituídos por filas sobre Redis, rodando dentro da própria API. Cinco processos a menos pra manter no ar, monitorar e reiniciar.
Agendamento e follow-up viraram jobs persistentes
Cada tarefa entra numa fila que sobrevive a reinício do servidor, com 3 retentativas automáticas e espera crescente entre elas. Se algo falha, a fila tenta de novo em vez de perder o trabalho.
Treze falhas de acesso fechadas
O escopo do cliente passou a ser aplicado em todas as consultas. Pedir o dado de outro escritório agora devolve 404 em vez de entregar o registro.
Rotas abertas fechadas e injeção de SQL corrigida
As cinco rotas sem autenticação passaram a exigir login, e a consulta vulnerável foi reescrita com parâmetros.
Webhooks passaram a validar origem
Cada chamada precisa apresentar o token da instância. O que não valida é descartado.
Credenciais fora do código
Todas as chaves saíram do código-fonte e passaram a vir de variáveis de ambiente.
CORS restrito e cabeçalhos de segurança aplicados
A API passou a aceitar só as origens conhecidas e a enviar os cabeçalhos de segurança que o navegador usa pra proteger o usuário.
Senha universal removida
No lugar dela, senha temporária gerada sob demanda no painel de controle: válida por 30 minutos, restrita a uma única conta, revogável a qualquer momento, guardada apenas como hash e exibida uma única vez a quem a gerou. A senha do próprio cliente continua valendo e não muda.
Autenticação reescrita com dois tokens
O token de acesso vive só em memória e dura 15 minutos. A renovação fica num cookie httpOnly, que o JavaScript da página não consegue ler. Nenhum token voltou a ser gravado no navegador.
Dados pessoais fora da telemetria
Telefone, nome e conteúdo de mensagem deixaram de ser gravados nos rastros de monitoramento, em conformidade com a LGPD.
Banco sob controle de migrações
A sincronização automática de esquema foi desligada em produção. Hoje são 77 migrações versionadas, aplicadas em ordem e com histórico do que já rodou.
Chaves primárias migradas para UUID
As 12 tabelas centrais deixaram de usar inteiro sequencial. Além de facilitar integração, tira do caminho a adivinhação de identificador que abria as falhas de acesso.
Suíte de testes de 8 para 63 arquivos
Mais de 770 testes rodando na última execução registrada, cobrindo o caminho crítico do sistema.
Serviços gigantes decompostos
Entre eles, um de 1.800 linhas. A quebra foi feita sempre começando pelos testes, pra garantir que o comportamento não mudasse no caminho.
Três consultas em cascata eliminadas
Relatórios, dashboard e kanban faziam uma consulta por item retornado. Viraram uma consulta agregada só.
Erro de escopo em relatório corrigido
Cada atendente estava vendo o total do escritório inteiro no lugar do próprio número.
Falha de envio isolada
Um erro ao enviar uma mensagem passou a ficar contido nela mesma, sem derrubar o restante do sistema.
Esteira de deploy automatizada
Publicar deixou de ser procedimento manual de madrugada de domingo.
Front-end migrado para Angular 18
Com design system próprio baseado em tokens: uma fonte única de verdade pra cor, espaçamento e tipografia, no lugar de valor solto espalhado pelas telas.
Tema claro e escuro completo
A paleta foi gerada a partir da marca da Juscia, com contraste verificado, e o tema acompanha a preferência do sistema operacional.
Paleta de gráficos validada para daltonismo
As séries continuam distinguíveis nos três tipos de deficiência de visão de cores, verificado por medição de distância de cor, não no olho.
Cinquenta e seis erros de acessibilidade corrigidos
E a verificação passou a travar a entrega se algum voltar.
Carregamento com esqueleto de conteúdo
No lugar de giradores, cada tela mostra um esqueleto com as mesmas medidas do conteúdo real, então a página não pula quando os dados chegam.
Painel de controle construído do zero
Treze telas, onde antes não havia nenhuma.
Planos modulares e acompanhamento de processos
Os dois recursos que a equipe anterior dizia serem impossíveis, entregues e funcionais em menos de uma semana.
Custo de infraestrutura reduzido em cerca de 75%
Revisões ociosas desligadas e recursos redimensionados pro uso real, sem tirar capacidade de quem usa.
Padronização de código e arquitetura
Um padrão único em todo o back-end, com as decisões de arquitetura registradas e documentação escrita por módulo, pra próxima pessoa não precisar adivinhar o porquê.
Os números

O que dá pra medir da entrega

Números apurados no próprio repositório do projeto, comparando o que existia antes com o que está no ar hoje.

Entrega
24

Falhas de segurança corrigidas, de brechas de acesso a credenciais expostas.

~75%

De redução no custo mensal de infraestrutura.

282

Endpoints que a API expõe hoje, sob um padrão único.

13

Telas no painel de controle que a Juscia não tinha antes.

Migrações de banco versionadas

arquivos de migração

No lugar da sincronização automática de esquema direto em produção.

Arquivos de teste no back-end

arquivos de teste

Mais de 770 testes rodando na última execução registrada.

Processos rodando em produção

processos

Os cinco serviços auxiliares em Python viraram filas dentro da própria API.

Cobertura de testes do back-end

42,6%
Linhas cobertasÚltima medição registrada, partindo de 8 arquivos de teste no projeto inteiro.

Falhas de segurança corrigidas, por tipo

  • Acesso indevido a dados de outro escritório13
  • Rotas sem autenticação5
  • Credenciais escritas no código3
  • Webhooks sem validação de origem2
  • Injeção de SQL1
Frente por frente

Segurança e acesso

Da senha universal às brechas entre escritórios, o que protegia menos do que devia.

Senha universal removidaSubstituída por senha temporária de 30 minutos, gerada sob demanda, restrita a uma conta e revogável.
Senha guardada só como hashExibida uma única vez a quem a gerou, nunca guardada em texto puro depois disso.
Treze brechas de acesso fechadasEscopo do cliente aplicado em todas as consultas, entre escritórios diferentes.
Rotas abertas e injeção de SQL corrigidasCinco rotas sem autenticação passaram a exigir login, e a consulta vulnerável foi corrigida.
Tokens fora do navegadorAcesso em memória por 15 minutos, renovação num cookie httpOnly que o JavaScript não lê.
Cabeçalhos de segurança e CORS restritoA API só aceita as origens conhecidas e envia os cabeçalhos que protegem o usuário.
Dados pessoais fora da telemetriaTelefone, nome e mensagem deixaram de ser gravados nos rastros de monitoramento, em conformidade com a LGPD.
Auditoria e bloqueio de IPTela de saúde do sistema, com bloqueio de IP manual ou automático.
Frente por frente

Confiabilidade da operação

Onde a operação parava de responder, e como ela passou a se recuperar sozinha.

Cinco serviços em Python saíram do arViraram filas rodando dentro da própria API.
Jobs persistentesAgendamento, follow-up e resposta sobrevivem a reinício do servidor.
Três retentativas automáticasPor job, com espera crescente entre uma tentativa e outra.
Falha de envio isoladaUm erro ao enviar uma mensagem não derruba mais o restante do sistema.
Três consultas em cascata eliminadasNos relatórios, no dashboard e no kanban.
Erro de escopo em relatório corrigidoCada atendente via o total do escritório inteiro; agora vê só o próprio número.
Frente por frente

Banco e arquitetura

Como os dados e o código passaram a ter controle de versão e um padrão único.

Sincronização automática desligadaO esquema do banco não muda mais sozinho em produção.
77 migrações versionadasAssumiram o controle do banco, em ordem e com histórico do que já rodou.
Chaves primárias em UUIDNas 12 tabelas centrais, no lugar do inteiro sequencial fácil de adivinhar.
Serviços gigantes decompostosA quebra foi feita sempre começando pelos testes.
Tipos em modo estritoVerificação ligada em todo o projeto, não só em partes novas.
Decisões de arquitetura registradasDocumentação escrita por módulo, pra próxima pessoa não precisar adivinhar o porquê.
Frente por frente

Interface e experiência

Do framework à acessibilidade, o que mudou pra quem usa o sistema todo dia.

Front-end migrado para Angular 18A base do front-end saiu de uma versão antiga direto pro Angular 18.
Design system baseado em tokensUma fonte única de verdade pra cor, espaçamento e tipografia.
Tema claro e escuro completoSegue a preferência do sistema operacional automaticamente.
Paleta gerada a partir da marcaContraste verificado, não só escolhido no olho.
Paleta de gráficos validadaPros três tipos mais comuns de daltonismo.
56 erros de acessibilidade corrigidosA verificação trava a entrega se algum erro voltar.
Esqueleto de conteúdo no carregamentoNo lugar de giradores, espelhando o layout real da tela.
Avisos e erros unificadosNuma camada só, no lugar de vários padrões espalhados.
Frente por frente

Painel de controle, que não existia

Treze telas que a equipe da Juscia não tinha antes, construídas do zero.

13 telas construídas do zero
Onde antes não havia nenhuma tela administrativa.
Visão geral da operação
Usuários, planos, pacotes e cupons, tudo numa tela só.
Agentes e custos
Custo de IA e custo de consulta processual.
Processos
Lista e o detalhe de cada um.
Auditoria e saúde do sistema
Acompanhamento do estado geral da operação.
IPs bloqueados
Bloqueio manual ou automático, com histórico de tentativas.
Senha temporária pelos gerentes
Emissão e revogação de senha temporária pra qualquer conta, direto do painel.
O resultado

Como a operação ficou

O que mudou no dia a dia de quem usa o sistema, depois da virada de arquitetura.

  • Mensagem perdida
    AconteciaNunca mais
  • Follow-up perdido
    AconteciaNunca mais
  • Bot deixava de responder
    AconteciaNunca mais
  • Agendamento perdido
    AconteciaNunca mais
  • Uma falha derrubava o servidor
    AconteciaNunca mais
  • Retentativa automática
    Não existia3 por job
Resumo

Juscia hoje

Tudo que mudou, reunido num único lugar.

Sistema estável e no arEm um mês, depois de dois anos sem conseguir sair do lugar.
Nada mais se perdeMensagem, follow-up ou agendamento: tudo virou job persistente com retentativa automática.
24 falhas de segurança corrigidasEntre elas, treze brechas de acesso a dados de outro escritório.
Acesso administrativo sempre temporárioGerado sob demanda, sem nenhuma senha universal.
Painel de controle com 13 telasUsado todos os dias pelos gerentes da Juscia.
Banco sob controle de 77 migraçõesNo lugar da sincronização automática em produção.
Suíte de testes, de 8 para 63 arquivosMais de 770 testes rodando na última execução registrada.
Custo de infraestrutura, cerca de 75% menorRedução no custo mensal de infraestrutura.
Custo de operação reduzidoA uma fração do que a equipe interna anterior consumia.
Recursos antes vistos como inviáveis, no arHoje em produção e usados pelos clientes da Juscia.
Dúvidas

Perguntas frequentes

Duas coisas que andam juntas. Colocamos agentes de IA pra trabalhar na operação da sua empresa: escolhemos com você onde começar, construímos e acompanhamos o resultado na Reliever, a nossa plataforma. E cuidamos do software por trás: auditamos e corrigimos sistemas que já existem e construímos MVPs do zero. Nos dois casos, programadores de verdade fazem o trabalho, com double check sempre.

Os três, no mesmo contrato. A consultoria define onde a IA gera resultado, os engenheiros constroem e colocam no ar, e a Reliever é onde os agentes rodam e são medidos. Plataforma sozinha costuma virar licença parada, e time sozinho não escala.

É a plataforma da Bootcom onde os agentes de IA são criados, operam e são medidos. Cada execução fica registrada e, onde o risco exige, uma pessoa do seu time aprova antes de o agente agir.

Pelo diagnóstico gratuito: uma conversa de 1 hora a 1 hora e meia com quem vai construir. Você preenche o formulário, a gente responde em até 10 minutos pra marcar, e você sai da conversa com prioridades claras, mesmo que não feche com a gente.

Até 30 dias, dependendo do escopo definido na etapa de diagnóstico. A IA acelera o que é repetitivo, uma pessoa revisa cada entrega, e testes, documentação e deploy automatizado entram desde o primeiro dia, pra o MVP se sustentar depois da validação.

Sim, é o caso mais comum. Passamos a IA pelo código, pela arquitetura e pela infraestrutura do que já existe pra encontrar falhas, arquitetura ruim, código ruim e desperdício, e entregamos um plano de melhorias por risco e impacto. Se quiser, a gente aplica as melhorias, sem precisar reescrever tudo do zero.

Em duas frentes. Na consultoria, a IA varre código, arquitetura e infraestrutura atrás de falhas que levariam dias pra achar na mão, e depois ajuda a aplicar as melhorias. No desenvolvimento, ela acelera o código repetitivo e os testes. Nos dois casos, programadores de verdade auditam o que a IA fez, com double check sempre: quem decide e responde pelo resultado é sempre uma pessoa do time.

Sim, oferecemos acompanhamento pós-lançamento. O escopo de suporte é combinado junto com a proposta, de acordo com a necessidade do projeto.

A stack é escolhida de acordo com o projeto, priorizando tecnologias maduras, bem documentadas e fáceis de manter, não a tecnologia mais nova por modismo.

Não. Se você não tem tudo definido, começamos pela etapa de diagnóstico, que existe justamente pra transformar uma ideia solta em escopo, prioridades e prazo claros.

Prazo e forma de pagamento são definidos junto com a proposta, geralmente dividido em etapas ligadas a entregas, não tudo adiantado nem tudo só no final.

Trabalhamos 100% remoto, com toda a comunicação por chamada, WhatsApp e repositório compartilhado. E, em Natal (RN), nossa cidade, podemos encontrar você pessoalmente: reunião, apresentação ou acompanhamento do projeto.

Sim, sem problema. Se o projeto exigir, assinamos o NDA antes mesmo da primeira conversa técnica mais aprofundada.

Dá. Começamos com a auditoria com IA do que já existe, o mesmo processo da consultoria, pra entender o estado real do código antes de assumir a manutenção ou continuar o desenvolvimento.

Sim. Você pode contratar suporte contínuo ou chamar a gente pontualmente pra novas funcionalidades, sem contrato de fidelidade obrigando isso.

Quer ser o próximo case da Bootcom?

Conte se você tem um sistema pra auditar ou um MVP pra construir do zero, e vamos conversar.

Entre em contato