O problema
Clínicas no Brasil rodam em uma stack que não anda há uma década — agendamento por telefone, prontuário em papel, conciliação manual quando procedimento divide receita entre clínica e profissional independente. Estamos construindo um SaaS que serve tanto o operador da clínica quanto o marketplace de profissionais que trabalham nela, com agendamento de primeira classe, descoberta de serviços e split de pagamento que não exige um financeiro pra calcular.
Arquitetura
Next.js 16 App Router sobre PostgreSQL via Prisma 7. Auth em Better Auth com hierarquia SUPER_ADMIN > ADMIN > CLINIC_MANAGER > PROFESSIONAL > PATIENT. Arquivos (prontuários, mídia de perfil) em MinIO em dev e storage S3-compatible em produção.
Tenant A Tenant B Tenant C
──────── ──────── ────────
ops da clínica profissional solo clínica + marketplace
│ │ │
└────────────────────┼────────────────────┘
│
Next.js 16 App Router · React 19
Better Auth · session-aware everywhere
│
┌────────────────┼────────────────┐
▼ ▼ ▼
PostgreSQL MinIO / S3 Splits de pagamento
(Prisma 7, (provider-agnostic,
valores webhook-driven)
em centavos)Disciplina arquitetural
Regra de quatro camadas que o código enforça:
UI Components → Hooks → Services → Repositories → Database (Prisma)Components e hooks nunca importam o client Prisma. Services nunca pulam repositories. API routes e server actions são finos: validam input via schemas Zod em src/schemas/, delegam pra um service, retornam via response helpers tipados (apiSuccess, apiList, apiError). O padrão mantém lógica multi-tenant single-sourced — todo read e write toca um repository que escopa por tenant.
Valores monetários armazenados como integers em centavos. finalValueInCents = transferValueInCents + commissionValueInCents. Zero float perto de código financeiro.
Prática de engenharia
Estou liderando engenharia — definindo arquitetura, escolha de stack, code review, cadência de sprint e onboarding técnico. Testes em Vitest com fixture PostgreSQL real (sem mock pra data layer; paridade com produção ganha de velocidade).
Status
Em construção ativa — primeiros tenants pagantes mirados pra meados de 2026. As decisões de arquitetura tomadas agora (multi-tenant desde o dia um, schema-first vindo do spec, queries repository-scoped) são desenhadas pra manter o custo de adicionar o décimo e o centésimo tenant linear, não exponencial.