Nesse artigo irei apresentar os motivos e os resultados das decisões técnicas que tomamos em um de nossos últimos projetos, o Dra. Legal. Mas de uma forma que qualquer um consiga entender!
Se você quer conhecer mais sobre o que é o Dra. Legal, leia esse nosso artigo aqui: Dra. Legal: quando a tecnologia aproxima as pessoas do Direito, em que nosso colega Lucas explica por que esse projeto merece destaque.
Agora vamos para o artigo…
TL;DR
- Se você quer lançar um produto digital, planejamento e pesquisa são essenciais! Podem economizar muito tempo (e dinheiro) no futuro próximo.
- Sempre avalie o preço e dificuldade. Às vezes vale mais a pena pagar caro no início para poder validar sua ideia rapidamente, e com muito menos dor de cabeça.
- Infraestrutura digital (servidores, domínio, email, etc…) são uma escolha difícil quando você está começando, por isso escolha aquele que você já está mais acostumado (PS: ou seja como eu, e escolha uma hospedagem em nuvem nova, e passe várias horas se acostumando e solucionando problemas novos).
O Maior dos Problemas
Quando os clientes chegaram para nós com a ideia de construir uma IA para democratizar e traduzir o “juridiquês”, achei que tarefa não ia ser tão difícil. Porém, uma das funcionalidades que deveria estar presente seria a de ler os processos judiciais do usuário para que a IA já tivesse essas informações em seu contexto.
Mas de onde iríamos ler esses processos? Como conseguiríamos acompanhar processos judiciais dos usuários cadastrados?
Temos várias opções hoje. Jusbrasil é, sem dúvida, a maior delas. Mas quando analisamos o preço, tivemos de dar um passo para trás.
Aí fomos verificar como poderíamos criar nossos próprios robôs para coletar e monitorar as bases judiciais (E-Proc e SAJ) e coletar essas informações. Mas sem chance: cada tribunal parecia ter seu próprio portal, e dar manutenção em mais de uma dezena de robôs ia ser muita dor de cabeça.
Só para vocês terem noção, enquanto pesquisava e ia a fundo no LinkedIn, vi que o Jusbrasil possui mais de 300 funcionários. Claro, a maior parte não deve ser da área técnica, mas da para ter uma noção do grau de manutenção e tamanho do sistema que eles têm (e nós estávamos pensando em replicar uma parte disso apenas em 4 pessoas).
No fim, a solução que escolhemos foi o Escavador (isso não é uma recomendação), pois seu modelo de consulta pré-pago nos caiu muito bem. E passamos a utilizá-lo para monitoramento e pesquisa de processos.
Então começamos a salvar uma cópia dos processos já pesquisados e, Voilà, passamos a ter os processos salvos em nossa base, eliminando consultas desnecessárias.
E agora, o medo do Facebook.
Ok, já estávamos conseguindo consultar os processos, mas e quanto às movimentações? E se um dos usuários recebesse um novo processo? Tínhamos de notificá-lo! E, para isso, a solução foi simples.
Definimos o disparo de e-mails e mensagens via WhatsApp, usando um sistema de filas para garantir que cada notificação de movimentação processual fosse disparada e seu envio registrado.
Mas, para o WhatsApp, não temos uma solução tão simples quanto o e-mail, e nosso cliente já havia tido más experiências com esses serviços de mensagens de WhatsApp, tendo algumas contas Meta banidas.
Ainda assim, conseguimos olhar para um leque de opções.
Poderíamos usar um provedor não oficial ou a própria API da Meta, mas o caminho que seguimos foi o de usar um provedor oficial, e selecionamos a Twilio.
O motivo? A incrível habilidade humana de jogar o problema nas costas dos outros.
Usando o serviço deles, teríamos menos diretrizes impostas pelo Facebook com que nos preocupar, contaríamos com um provedor reconhecido e simplificaríamos a integração. Sim, o serviço deles é caro, mas aceitável em nosso caso, visto o volume de mensagens que estávamos esperando. E, terceirizando parte da integração, correríamos menos riscos de sermos banidos ou de termos nossa conta Meta suspensa. Mas é claro: de forma alguma pretendemos usar a API do WhatsApp de maneira maliciosa ou de um jeito que viole suas diretrizes de utilização.
Pense grande, mas, se a empresa for enxuta, use as ferramentas compatíveis.
Outra escolha foi a da hospedagem dos servidores e infraestrutura (site, backend, banco de dados, etc). E por mais que a ideia pareça ser complexa, e que fossemos precisar de um servidor dedicado ou algo mais potente ($$$), logo de início já começamos a utilizar o Supabase (quem já vibe codou algo deve conhecer), que nos ofereceu autenticação, banco de dados, e uma gama de outros serviços essenciais para um SaaS. E, durante o desenvolvimento, não chegamos a ultrapassar sua cota gratuita.
Mas antes de lançar adquirimos um plano pago para ter um respiro, caso a carga aumentasse.
Julho de 2026…
Foi o mês em que o Dra. Legal foi ao ar. E depois de alguns meses desenvolvendo, vários aprendizados vêm à tona.
Neste artigo, tentei reunir os principais deles. Mas sem dúvida, o mais importante conselho que posso dar aos nossos leitores, ainda mais nos tempos obscuros em que estamos vivendo hoje (com o GPT 5.6 e o Claude Fable 5 aterrorizando os devs), é que vocês não devem subestimar as dificuldades técnicas. Uma equipe dedicada e preparada ainda é essencial para o sucesso de um projeto de software.
Por isso convido vocês a compartilharem suas experiências e, é claro, a contarem com a Beyonders para seus próximos projeto!
Forte abraço!