Marketplace · Saúde·2026
MEDSPACE
MVP no ar em ~4 semanas · 105 testes automatizados · 13 falhas de segurança corrigidas
- Papel
- Engenheiro único: arquitetura, implementação, segurança, deploy e manutenção contínua
- Período
- Mar 2026 → atual · em produção
Resumo
Marketplace onde médicos encontram clínicas que anunciam salas de consultório, aparelhos e ofertas de educação médica. O anunciante gerencia os próprios anúncios; uma fila de moderação no admin controla o que vai ao ar; os leads saem para o WhatsApp com mensagem pré-preenchida. O MVP subiu em ~4 semanas e evolui em incrementos pagos desde então.
Arquitetura e decisões
- Next.js App Router com Server Actions para mutações e Route Handlers só onde há de fato um contrato HTTP. Sem camada de API criada por hábito.
- Prisma sobre PostgreSQL (Supabase) com o schema como fonte única da verdade; migrations barram todo deploy.
- Auth.js v5 com credenciais bcrypt; a sessão é a fronteira de autorização, e toda Server Action revalida a posse do recurso em vez de confiar no cliente.
- Tipos de anunciante modelados como união discriminada (médico / clínica / empresa / coworking / instituição), então a validação CPF-vs-CNPJ e as regras do anúncio derivam do tipo, não de ifs espalhados.
- Anúncio nunca é publicado direto: criar/editar grava uma revisão pendente, e só a aprovação do admin torna público. Editar um anúncio aprovado o devolve à revisão.
- Rate limiting nas ações sensíveis via Upstash Redis, configurado fail-closed: se o Redis cair, a requisição é negada, não liberada.
- Schemas Zod compartilhados entre formulário e Server Action, então cliente e servidor validam contra o mesmo contrato.
Desafios
Problema: Auditei meu próprio código em produção e encontrei 13 vulnerabilidades: uma crítica.
Solução: A crítica permitia um anúncio chegar à listagem pública sem passar pela moderação. Vieram três altas: bloquear usuário era no-op, o rate limiter falhava aberto e o login vazava existência de conta por timing oracle. Os 13 foram corrigidos e retestados; o login virou tempo constante, o limiter fail-closed, e headers CSP/HSTS entraram. O banco foi copiado logicamente antes de qualquer mudança subir.
Problema: A conformidade com a LGPD tinha que ser real, não um banner de cookies.
Solução: O consentimento é capturado no cadastro e versionado contra os termos aceitos, então uma mudança futura de termos é comprovável. Cookies são opt-in via Google Consent Mode v2. O usuário exclui a própria conta e exporta seus dados em /api/me/export. Autoatendimento, sem chamado.
Resultados
- MVP em produção em ~4 semanas; 94 commits ao longo do projeto
- 105 testes automatizados: unitários, integração e E2E com Playwright
- 13 achados de segurança encontrados e corrigidos (1 crítico, 3 altos) em auditoria por iniciativa própria
- Incremento de jun/2026: +3.335 linhas, 50 arquivos alterados, 105 testes verdes
- Rastreamento de conversão Google Ads + Meta instrumentado para o lançamento pago