Lume

MVP em desenvolvimento ativo. Build solo. 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, então 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.