Escritório de advocacia acumula ferramenta: WhatsApp para agenda, planilha para caso, Drive para documento, formulário genérico para lead. O cliente liga pedindo status. A advogada não tem um painel. O problema não é falta de software. É excesso de software desconectado.
A plataforma que o site já descreve junta site, agenda, casos, documentos e honorários num lugar. A parte que interessa de engenharia: o isolamento do cliente não pode depender do React.
Por que RLS, e não “filtro na query”
Row Level Security no Postgres é a regra no banco. Cada tabela com política. Storage de documento com visibilidade por cliente. Autenticação no mesmo backend (Supabase, no case). Sem servidor próprio para o escritório individual manter.
O que isso muda na prática:
- a advogada vê o escritório inteiro no admin — leads, agenda do dia, casos, honorários;
- cada cliente autenticado vê só os próprios casos, documentos e mensagens;
- se o frontend tiver um bug e pedir o id errado, o banco não entrega o processo do outro.
Filtro só na API é o mesmo vício do SaaS de barbearia: funciona no caminho feliz. RLS é o caminho infeliz.
O que a plataforma entrega — sem inventar
Do que já é público no case: blog editável, upload de documento, agenda por disponibilidade da semana, canal de mensagem ligado ao caso, honorários e comprovante. Autonomia da advogada sem deploy a cada texto. Área do cliente sem ligar pedindo atualização.
Não vamos citar volume de processos, preço nem nome de escritório além do que o site já mostra. A tese é replicável para outro profissional liberal — o case já diz isso. A arquitetura não é.
Postgres, não slide de “zero trust”
RLS mal escrito é teatro do outro lado: política que using (true) em produção, ou service role no client. A disciplina é a mesma do medallion: o contrato fica onde o dado mora.
Se a sua “área do cliente” ainda é um where user_id = que alguém pode esquecer, escreve. Plataforma com regra no banco, não no front.