O problema
O serviço escalava até o limite de uma agenda
A entrega dependia de o fundador conduzir cada cliente pessoalmente. O modelo era lucrativo e tinha demanda — mas o teto era o número de horas de uma pessoa, e ele já estava encostado nele.
A pergunta certa não era "que features o produto precisa ter". Era qual pedaço do trabalho manual pode virar software sem quebrar o resultado que o cliente compra. Nem tudo podia.
- Onboarding de cliente feito por chamada, uma a uma
- Cobrança emitida à mão, com controle em planilha
- Nenhum caminho para o cliente se servir sozinho
- Risco real: virar produto genérico e perder o que diferenciava o serviço
A decisão técnica
Construir para o primeiro pagante, não para o pitch
Recusei o escopo inicial, que previa painel de administração completo, relatórios avançados e integrações antes do lançamento. Nada disso teria um usuário no dia em que ficasse pronto.
O corte foi o caminho mais curto entre um desconhecido e uma assinatura ativa.
Tudo que não estivesse nesse caminho ficou para depois do primeiro pagamento entrar.
- Multi-tenant desde o primeiro commit — retrofit de isolamento de dados é caro e arriscado
- Cobrança recorrente com provedor estabelecido, sem construir motor de pagamento
- Onboarding self-service para o caso mais comum; os casos raros continuaram manuais de propósito
- Telemetria de uso antes de features novas, para decidir com dado em vez de opinião
Arquitetura
Como está montado
Cada conta com escopo garantido no nível do banco, não só na consulta da aplicação. Vazamento entre clientes é o erro que não se recupera.
Sessão, convite de membro e recuperação de acesso resolvidos com biblioteca madura. Autenticação caseira é dívida disfarçada de economia.
Assinatura, trial e falha de pagamento tratados via webhook idempotente. Webhook que processa duas vezes cobra duas vezes.
Fluxo curto com estado salvo: quem abandona no meio volta de onde parou em vez de recomeçar.
Renderização no servidor para as telas públicas, cache na borda. Core Web Vitals medidos em produção, não no laptop.
Deploy automatizado a cada merge, migração de banco versionada e caminho de rollback testado antes de ser necessário.
Prova executável
Duas dessas linhas você pode testar agora
Cobrança duplicada e vazamento entre contas são os dois erros mais caros de um SaaS: o primeiro devolve dinheiro, o segundo devolve confiança. Os dados aqui são de demonstração — a lógica é a mesma que vai para produção.
Estado da assinatura
Dispare um evento e depois use reenviar último webhook: o provedor reenvia o mesmo evento quando não recebe confirmação, e o handler precisa reconhecer o id em vez de cobrar de novo.
Log de eventos recebidos
Consulta executada
Desligue o filtro para ver o que um where esquecido devolve. Em
produção o escopo é garantido no banco justamente porque essa linha é fácil de
omitir numa consulta nova.
Resposta da API
O que ficou de pé
Resultado
Os números abaixo estão marcados como pendentes de propósito. Este é um protótipo do site — quando os dados reais existirem, eles entram aqui.
O ganho que não vira número
O crescimento parou de custar agenda do fundador. Cada novo cliente passou a entrar por um caminho que já existe, em vez de exigir uma chamada inédita.