Plumaa
Plataforma de saúde mental para pessoas, psicólogos e empresas
Entrei quando a Plumaa ainda era só uma ideia. Escolhi a stack, modelei o banco e construí o backend de uma plataforma de saúde mental com três públicos: pessoas que buscam terapia, psicólogos e empresas.
Em 30 segundos
- Único desenvolvedor de backend desde a ideia: escolhi a stack (NestJS, Prisma, PostgreSQL) e modelei o banco.
- Cinco perfis com permissão decidida no backend, pagamentos com Stripe, agenda com Google e um pipeline de IA para prontuários.
- Em produção, com ~100 contas ativas; o resumo com IA economiza de 3 a 8 horas por semana para cada psicólogo.
- Quando
- jan 2026 — atual
- Papel
- Desenvolvedor Full-Stack · único dev de backend
- Time
- até 3 devs
- Stack
- React (Vite), NestJS, Prisma, PostgreSQL, Graphile Worker, Stripe, Google APIs, Claude, Deepgram
Contexto
A Plumaa é uma plataforma de saúde mental. Pessoas compram sessões avulsas ou planos para fazer terapia com psicólogos parceiros; psicólogos gerenciam agenda e atendimentos; e empresas usam um produto separado para mapear riscos psicossociais, como pede a norma NR-1.
É uma startup pequena: o time técnico chegou a no máximo três pessoas. Hoje são cerca de 100 contas ativas, somando clientes, psicólogos, empresas e funcionários dessas empresas.
O problema
Um único backend precisava servir cinco perfis com visões muito diferentes dos mesmos dados, e parte desses dados é de saúde. Um psicólogo não pode ver o que é de outro, uma empresa não pode ver as respostas individuais dos funcionários, e ninguém fora do admin pode chegar perto do resto.
Além disso: cobrança de sessões e assinaturas, agenda entre fusos horários, e psicólogos gastando horas por semana escrevendo prontuários à mão depois das sessões. Tudo com um time mínimo e na velocidade de uma startup.
Minha parte
Fui o único desenvolvedor de backend. Escolhi a stack, modelei o banco de dados e a estratégia de acesso e armazenamento, e ajudei a montar o time, conduzindo as entrevistas técnicas. O frontend ficou com os outros devs; eu revisava as entregas no staging e repassava cada mudança da API com a documentação do Swagger.
- Controle de acesso dos cinco perfis: cliente, psicólogo, empresa, funcionário e admin.
- Pagamentos com Stripe: sessões avulsas, planos com benefícios e a assinatura das empresas.
- Agenda com Google Calendar e login com Google.
- Produto B2B de NR-1: questionário por link público com validação de acesso e o cálculo dos riscos no banco.
- Pipeline de IA que transcreve a sessão e gera o rascunho do prontuário.
- Registro de eventos do sistema (sessão iniciada, transcrição iniciada, pagamento feito) para o painel do admin.
- Testes unitários e de integração cobrindo todas as rotas e serviços do backend.
- Infraestrutura: backend e banco na Digital Ocean, frontend na Vercel, staging espelhando a produção.
Decisões técnicas
Permissão sempre no backend
O cookie de sessão diz quem é o usuário e qual o perfil dele. Antes de qualquer consulta chegar ao repositório, uma camada define quais tabelas e colunas aquele perfil pode ler. O que está fora disso responde 404, sem nem confirmar que o recurso existe.
Postgres para tudo, sem Redis
As tarefas em segundo plano rodam no Graphile Worker, uma fila guardada no próprio PostgreSQL. Com a carga de hoje, é um serviço a menos para pagar, monitorar e manter no ar.
Stripe Checkout e webhooks idempotentes
O pagamento acontece na página da Stripe, então o dado do cartão nunca passa pelo nosso servidor. O acesso só é liberado quando chega o webhook, e cada transação é registrada: se o mesmo evento chegar duas vezes, ele é ignorado.
Agenda em UTC
Todos os horários são salvos em UTC e convertidos pelo fuso de atendimento do psicólogo. A reserva é uma tentativa: o horário só segue para o pagamento se ainda estiver livre.
No Google, dois escopos: todo mundo usa o login, mas só o psicólogo concede acesso à agenda.
IA assíncrona e anonimizada
Quando a sessão termina, um job assume: transcreve com a Deepgram, remove da transcrição os dados pessoais que o banco já conhece e manda o texto para o Claude estruturar o prontuário. O psicólogo recebe um rascunho em vez de uma página em branco.
Pequeno, mas pronto para crescer
Uma máquina para cada serviço, no plano mais simples, porque a demanda não pedia mais. O banco só aceita conexões do backend, tem backup diário, e o staging replica o ecossistema inteiro a partir da branch de desenvolvimento.
Arquitetura
Resultado
A plataforma está em produção, com cerca de 100 contas ativas entre os três públicos. O resumo de sessão com IA economiza de 3 a 8 horas por semana para cada psicólogo que usa, tempo que antes ia para escrever prontuários de memória.
O bug do boleto
Na feature de assinaturas, passamos dias testando no staging: crédito, débito, cartão recusado, expirado, sem saldo, timeout. Subimos, funcionou. Aí um cliente clicou em “pagar com boleto”: alguém tinha ativado essa opção direto no painel da Stripe, e a versão que testamos não tinha.
Revertemos a configuração e ajudamos a pessoa a concluir o pagamento. A lição que ficou: sempre vai existir um cenário que você não testou. O objetivo não é zero bugs, é zero impacto.