Lume

MVP em desenvolvimento ativo. Build solo, ponta-a-ponta. O case descreve decisões já travadas ou em construção — itens abaixo do bloco "Em construção" estão escopados mas ainda não entregues.

O problema

Psicólogo autônomo no Brasil toca a clínica com uma stack desconectada: WhatsApp pra agendar, caderno ou Word pra anotação, planilha pra cobrança, Google Calendar pra agenda, e processo separado pra emitir nota fiscal. Nada conversa. O custo não é ferramenta; é a carga cognitiva de costurar tudo entre uma sessão e outra.

As ferramentas existentes de gestão de consultório no Brasil ou:

1. Escondem o registro clínico atrás de burocracia pesada — foram feitas pra clínica de 20 profissionais, não pra psicólogo solo com 30 pacientes ativos.
2. Aparafusam IA como gimmick — botão "resumir a sessão" que alucina sem contexto, ou pior, substitui a anotação do psicólogo pelo output da IA e perde o original.

Quis fazer algo que um psicólogo solo conseguisse começar a usar em cinco minutos, onde a IA estrutura a anotação dele sem nunca ser fonte da verdade.

A abordagem

Quatro princípios de produto guiaram cada decisão de arquitetura:

1. A IA sugere, nunca finaliza no silêncio. O fluxo é fixo: psicólogo escreve → clica "Finalizar" → IA propõe campos estruturados → psicólogo revisa e edita → psicólogo confirma. O output estruturado é rascunho, não decisão.
2. O registro bruto é sagrado. Cada sessão finalizada guarda o texto original livre, os campos estruturados que o psicólogo aprovou, snapshot do template ativo naquele momento, versão do prompt e modelo usado. Se os campos forem editados depois, a mudança vai pra audit_logs. A anotação original nunca é sobrescrita.
3. Multi-tenant desde o dia 1. Mesmo o MVP sendo um psicólogo por conta, o schema já tem workspaces, workspace_members, e roles com RLS no Postgres ligado. Adicionar perfil de secretária depois vira mudança de permissão, não migration.
4. Sessão e cobrança são domínios separados. Cada sessão gera uma cobrança, mas vivem em tabelas diferentes com máquinas de estado independentes. No-show, pagamento parcial, cortesia e estorno viram regras locais em vez de vazarem entre o clínico e o financeiro.

Arquitetura

Toda query operacional filtra por workspace_id; row-level security no Postgres aplica isso na camada do banco — bug no app não vaza entre tenants. Trabalho longo (extração de IA, update de resumo, sync de Calendar) roda em fila, não no request handler. O endpoint de finalizar sessão retorna imediatamente e a UI faz polling do resultado da IA.

Decisões técnicas & trade-offs

Por que Supabase + Postgres em vez de NoSQL? O domínio é relacional em toda camada (workspace → pacientes → sessões → prontuário → cobranças → notas fiscais). RLS no banco é inegociável pra dado sensível de saúde. Supabase empacota auth

• Postgres + storage numa conta, o que comprime o build solo.

Por que separar login Google da integração com Google Calendar? Escopo OAuth. Pedir calendar.events no signup afunda a conversão — o usuário ainda nem viu o produto. Login usa só openid/profile/email; Calendar é consentimento separado oferecido no passo 3 do onboarding e em configurações. O sistema funciona pleno sem Calendar conectado.

Por que update incremental do resumo do caso? O "resumo consolidado" do paciente fica no topo do perfil dele e reflete a trajetória inteira do tratamento. Abordagem ingênua: regenerar de todas as sessões toda vez. Isso explode tokens e latência conforme a relação cresce. O Lume manda o resumo anterior + o brief da sessão nova pro Claude e pede a próxima versão. Custo constante por sessão, qualidade linear.

Por que nunca mandar dado identificável do paciente no prompt? Defesa em camadas. O conteúdo clínico vai; nome, CPF e e-mail do paciente não. Se o provedor do modelo for comprometido ou mal-configurado, o conteúdo vazado não consegue ser ligado a uma pessoa identificável sem um join separado pelo nosso banco.

Entregue vs. em construção

Entregue (escopo MVP travado):

• Workspace, perfil profissional e wizard de onboarding
• CRUD de paciente com soft-delete (inativo, nunca deletado)
• Agenda com vistas dia e mês, detecção de conflito, fluxo de no-show
• Editor de sessão com auto-save e finalização assistida por IA
• 3 campos padrão de análise: queixa, resumo breve, evolução
• Cobranças geradas automaticamente ao concluir a sessão

Em construção:

• Homepage pública e página de preços (design do brand system)
• Assinatura Stripe com trial de 14 dias
• Sync bidirecional do Google Calendar (V1 é só sistema → Google)
• Surface dos audit logs na UI (a tabela é populada; o viewer admin ainda não foi construído)

O que eu faria diferente — perguntas em aberto

• Validar o loop de IA com psicólogo real antes de afinar o prompt. Tenho schema, template de prompt e três campos padrão. Ainda não sentei com psicólogo em exercício e vi ele finalizar uma sessão. Fazer isso vale mais que qualquer upgrade de modelo.
• Não entregar UI de templates no v1. O modelo de dados suporta templates versionados com campos custom por workspace. O produto v1 entrega os três campos padrão hard-coded. O editor de template mora no schema pra flexibilidade futura, não na UI ainda.
• Questionar a feature de recorrência. Quase todo paciente tem horário fixo semanal, então recorrência parece essencial. Mas todo concorrente que olhei tem isso e uma máquina de estado confusa em torno de exceções ("essa semana mudamos pra quinta"). Prefiro entregar sem e adicionar quando os modos de falha aparecerem em uso real.

Status & links

• Demo ao vivo: lume-psico.vercel.app
• GitHub: MarcosNespolo/lume
• Marca & design system: teal frio + mint, calmo e clínico — documentado internamente; homepage pública sai com o lançamento do v1.