Documentação da Plataforma · Junho 2026

O sistema operacional dos laboratórios de prótese dentária

RALab conecta laboratórios e dentistas numa só plataforma: o dentista faz o pedido, o laboratório produz e entrega, e os dois acompanham tudo em tempo real — do orçamento à entrega.

SaaS multi-tenantReact + Supabase Multi-portal (Lab · Dentista · Admin)LGPD-ready
Parte 1 — Conceitual

O problema que resolvemos

O laboratório de prótese dentária vive um caos operacional invisível. Pedidos chegam por WhatsApp, papel e ligação. O acompanhamento é manual. A comunicação com o dentista se perde. E a gestão financeira mora em planilhas.

📋

Pedidos dispersos

Ordens de serviço entram por canais soltos. Sem padrão, sem rastreio, sujeitas a erro e retrabalho.

🔌

Dentista no escuro

O cliente (dentista) não tem visibilidade do status do seu trabalho. Cobra por telefone, gera ruído.

📊

Gestão na planilha

Produção, prazos, comissões e financeiro vivem fora de um sistema. Não escala, não dá métrica.

A solução

Uma plataforma única, multi-portal, que digitaliza toda a operação do laboratório e abre um canal direto e profissional com o dentista.

🦷

Portal do Dentista

O dentista cria a ordem de serviço com odontograma interativo, acompanha o status em tempo real e conversa com o lab. É o coração do produto.

🏭

Portal do Laboratório

Gestão completa: OS, produção por etapas, clínicas, dentistas, catálogo de serviços, tabelas de preço, financeiro e chat.

⚙️

Painel do SaaS (Admin)

Visão de toda a plataforma: laboratórios, assinaturas, faturas, planos, métricas (MRR, churn) e cobrança.

Parte 2 — A jornada

Como funciona, na prática

Do pedido à entrega, com comunicação e status em tempo real — sem WhatsApp solto, sem papel.

1 · Dentista cria a OS
2 · Lab recebe e orça
3 · Produção por etapas
4 · Status em tempo real
5 · Entrega + financeiro

Para o dentista

  • Cria o pedido escolhendo dentes no odontograma (padrão FDI) e serviços do catálogo
  • Acompanha o status de cada OS (orçamento → aprovada → produção → pronta → entregue)
  • Conversa com o laboratório por OS, com confirmação de leitura (✓✓)
  • Recebe notificações a cada mudança — no app e (em breve) por e-mail/WhatsApp

Para o laboratório

  • Recebe a OS na fila, precifica e aprova
  • Gerencia produção por etapas customizáveis (com cores e ordem)
  • Cadastra clínicas, dentistas, serviços e tabelas de preço
  • Acompanha financeiro e responde no chat
Parte 3 — Modelo de negócio

SaaS por assinatura

Cada laboratório é um tenant isolado. A receita é recorrente, por plano mensal, com cobrança via PIX/boleto (mercado brasileiro) ou cartão.

Plano Essencial — R$ 69/mês

  • Até 3 usuários
  • Até 100 OS/mês
  • 1 tabela de preços
  • Portal do dentista: não incluso

Plano Profissional — R$ 139/mês

  • Usuários ilimitados
  • OS ilimitadas
  • Tabelas de preço ilimitadas
  • Portal do dentista incluso (diferencial)
Entitlements no código. Os limites de cada plano (usuários, OS/mês, portal do dentista) são checados no banco via a função lab_has_feature() — não são apenas texto na página de preços. Trocar preço ou limite de um plano é feito pelo painel admin, sem deploy.

Cobrança: dois modos

ModoComo funcionaStatus
ManualAdmin emite a fatura, o lab paga (PIX/boleto manual), admin marca como paga e a assinatura é ativada/renovada por +1 mês.Pronto
Automático (Asaas)O lab gera a cobrança PIX/boleto pelo próprio painel; o gateway confirma o pagamento via webhook e ativa a assinatura sozinho. Dunning automático em falha. Estrutura pronta — falta plugar a key
Parte 4 — Técnico

Arquitetura

Aplicação single-page (React) sobre um backend serverless gerenciado (Supabase: Postgres + Auth + Realtime + Storage + Edge Functions). Sem servidor para manter.

┌─────────────────────────────────────────────────────────────┐ │ NAVEGADOR (React SPA — Vite + TypeScript + shadcn/ui) │ │ • Portal Lab • Portal Dentista • Painel Admin │ └───────────────┬─────────────────────────────────────────────┘ │ HTTPS · JWT do usuário ▼ ┌─────────────────────────────────────────────────────────────┐ │ SUPABASE (projeto dedicado, região São Paulo) │ │ │ │ Auth ─ login, papéis (admin/lab/funcionário/dentista) │ │ Postgres ─ dados + RLS (isolamento multi-tenant) │ │ Triggers ─ total da OS, notificações, numeração │ │ Realtime ─ chat e notificações ao vivo │ │ Storage ─ anexos das OS (radiografias/fotos) │ │ Edge Functions ─ gateway de pagamento, e-mail, WhatsApp │ └───────────────┬─────────────────────────────────────────────┘ │ ┌────────┴─────────┬──────────────────┐ ▼ ▼ ▼ Asaas (PIX/boleto) Resend (e-mail) Evolution (WhatsApp)

Stack

CamadaTecnologia
Front-endReact 18 + Vite + TypeScript, Tailwind CSS, shadcn/ui (Radix)
Estado / dadosTanStack Query (cache + sincronização), React Hook Form + Zod
BackendSupabase — Postgres gerenciado, Auth, Realtime, Storage
Lógica serverFunções SQL SECURITY DEFINER + Edge Functions (Deno)
IntegraçõesAsaas (pagamento), Resend (e-mail), Evolution API (WhatsApp)
DeployCloudflare Pages (front) + Supabase (backend)

Modelo de dados (entidades principais)

DomínioTabelas
Tenant & pessoaslabs, lab_members, dentists, clinics, profiles, user_roles
Operaçãoorders, order_items, order_stage_history, order_attachments, production_stages
Catálogoservices, service_categories, price_tables, price_table_items
Comunicaçãoconversations, chat_messages, notifications
Billingplans, plan_features, subscriptions, invoices, usage_counters, coupons
Técnico

Segurança & isolamento multi-tenant

O ponto mais crítico de um SaaS multi-tenant: garantir que um laboratório nunca veja os dados de outro. No RALab isso é garantido no banco, não no front.

Row Level Security (RLS)

Toda tabela tem políticas no Postgres que filtram cada linha por lab_id e pelo papel do usuário. Mesmo que o front falhe, o banco recusa o acesso. A segurança é estrutural.

Quatro papéis

admin (dono do SaaS), lab_owner, lab_employee e dentist — cada um enxerga exatamente o que deve. O dentista, por exemplo, só vê as próprias OS.

Funções com privilégio controlado

Operações sensíveis (criar OS atômica, cobrança, métricas cross-tenant) usam funções SECURITY DEFINER que validam o papel internamente antes de agir.

Validado de ponta a ponta

Os fluxos críticos foram testados autenticando como usuário real — incluindo a prova de que um dentista não consegue ver ou criar dados fora do seu escopo.

Exemplo real de política: o dentista só cria uma OS se ela for dele, do laboratório ao qual está vinculado e com status inicial "orçamento" — verificado no banco a cada inserção.
Parte 5 — Estado atual

O que já está pronto

3
portais funcionais
100%
multi-tenant seguro (RLS)
2
planos com cobrança
✓✓
chat com leitura
0

Fundação de segurança Pronto

RLS por papel, guards de acesso, isolamento multi-tenant, vínculo de identidade.

1

Portal do Dentista Pronto

Dentista cria OS (odontograma + serviços), acompanha status, conversa com o lab. O pitch do produto, funcionando.

2

Plataforma SaaS Pronto

Planos, assinaturas, faturas, entitlements, painel de super-admin com métricas (MRR) e cobrança manual operacional.

3

Comunicação Pronto (in-app)

Notificações em tempo real + sino + confirmação de leitura no chat. Canais e-mail/WhatsApp: estrutura pronta.

4

Gateway automático & canais externos Estrutura pronta

Cobrança automática via Asaas (PIX/boleto), e-mail (Resend) e WhatsApp (Evolution) — Edge Functions escritas, faltando apenas conectar as chaves.

5

Profundidade operacional Próximo

Anexos de radiografia, kanban de produção com SLA, comissões, contas a pagar, PDF da OS.

Por que isso é defensável

🔗

Efeito de rede

Cada laboratório traz seus dentistas para a plataforma. Quanto mais dentistas usam, mais difícil trocar de fornecedor.

📈

Receita recorrente

SaaS por assinatura com baixo custo marginal — infra serverless escala sem time de operações.

🇧🇷

Feito para o Brasil

PIX/boleto nativos e WhatsApp como canal — exatamente onde o mercado de laboratórios já está.