Estudos de caso, notas de sistema e encaixe de vaga organizados na mesma superfície editorial.
Repo público
OnboardPulse
Um SaaS multi-tenant de onboarding com billing, automação de follow-up, storage controlado e documentação operacional.
Por que este caso importa
Este projeto mostra trabalho além de CRUD: isolamento entre tenants, orçamento de IA, webhooks de cobrança, política de storage e follow-ups via cron.
Repo público, projeto ativo do portfólio
O que inspecionar primeiro
Comece pela superfície do repositório: README, caminho de setup, CI, docs e os blocos de evidência que mostram que o sistema sobrevive fora do caminho feliz.
Abrir repositórioContexto
Eu queria um projeto SaaS que parecesse mais com operação de dia dois do que com landing page bonita. OnboardPulse é um produto de onboarding para agências e times B2B em que a parte difícil não são os formulários, mas sim isolamento entre tenants, ciclo de cobrança, uploads e jobs de follow-up.
Problema
Onboarding de cliente se fragmenta rápido: pedidos de documento, lembretes, estado de pagamento, trial e isolamento de conta acabam virando trabalho manual. O produto precisava centralizar esse fluxo em um sistema que também fosse explicável para outro engenheiro.
Restrições
- Toda entidade de domínio precisava ficar escopada por
organizationId. - Billing precisava de tratamento idempotente para webhooks do Mercado Pago.
- Uploads precisavam suportar desenvolvimento local e produção com S3 compatível.
- Uso de IA precisava de teto de custo em vez de chamadas irrestritas.
Prova centralIsolamento multi-tenant + ciclo de billing
Sinal do repositórioDocs de launch e runbook de deploy
Preocupação operacionalCron, webhooks e modos de storage
Arquitetura
Next.js App Router
-> server actions / routes
-> services de domínio
-> Prisma + Postgres
-> Mercado Pago + Gemini + storage S3-compatible
Rota operacionalFronteira do tenant, billing, storage e follow-up automatizado
01Criar a fronteira do tenant
O signup cria um espaço escopado por organização, com trial e ownership definidos para tudo o que vem depois.
02Passar upgrade pelo billing
Preferências do Mercado Pago e replay seguro de webhook decidem quando a assinatura pode ficar ativa sem duplicar estado.
03Mover documentos em storage controlado
Uploads funcionam no ambiente local e depois trocam de forma limpa para storage compatível com S3 quando o deploy fica real.
04Gerar follow-up com cheque de custo
Os follow-ups via cron só avançam quando teto de uso e estado da conta continuam dentro do que o produto permite.
Decisões e trade-offs
- O isolamento entre tenants é explícito na aplicação, em vez de depender de RLS desde o primeiro dia.
- O controle de orçamento de IA é conservador e aproximado, que é o trade certo para custo inicial.
- Storage fica local no desenvolvimento, mas troca de forma limpa para S3/R2 em deploy real.
- A documentação é prática de propósito: launch guide, deploy em Vercel e checklist de QA em vez de só texto abstrato.
O que funcionou
- O repo demonstra amplitude de engenharia de produto: auth, cotas, billing, cron, storage e CSP.
- A documentação de deploy faz o projeto parecer operacional, não aspiracional.
- O checklist de QA é bom material de entrevista porque mostra exatamente os modos de falha considerados.
O que ainda está incompleto
- Alguns itens do roadmap ainda precisam de cobertura automatizada mais forte, principalmente em billing.
- Ainda não existe URL pública de produção anexada.
- RLS está documentado como etapa futura, mas ainda não foi implementado.
Evidência
Target do cron no Vercel:
POST /api/jobs/run-followups?secret=CRON_SECRET
QA rápido:
- trial expirado bloqueia ações com 402
- replay de webhook não duplica PaymentLog
- org A não acessa dados da org B