O que um boilerplate de SaaS entrega, e o que você ainda vai ter que construir

Um boilerplate de SaaS entrega as partes que são idênticas em todo SaaS, como autenticação, cobrança, painel administrativo, internacionalização e CI/CD, e nenhuma das partes que fazem alguém pagar pelo seu produto. Em geral a troca compensa, mas só se você souber exatamente onde essa linha cai antes de comprar. O CastorStack é a implementação de referência usada abaixo.

O que já vem pronto de verdade

Uma base pronta para produção entrega o encanamento que tem uma única resposta certa e nenhuma diferenciação de produto:

• Autenticação: cadastro, login, recuperação de senha, gestão de sessão e rotas protegidas em todos os frontends. No CastorStack isso roda sobre o Supabase, com a sessão validada no servidor pela API em vez de confiada ao cliente.
• Cobrança ligada de ponta a ponta. Não um campo para a chave da Stripe, mas um endpoint de checkout real, handlers de webhook assinado, e os registros de acesso que esses webhooks gravam. O CastorStack traz Stripe e Paddle, com uma regra de roteamento por país que decide por qual deles cada comprador passa.
• Um modelo de produtos e preços: produtos, planos, features e os vínculos entre eles, editáveis por um painel em vez de constantes espalhadas pelo código.
• Um painel administrativo com busca de usuários, estado das assinaturas, configuração dos provedores de pagamento, feature flags e logs de auditoria.
• Internacionalização: roteamento por idioma, arquivos de tradução e seletor de idioma em cada app. Colocar i18n depois do lançamento é uma das refatorações mais miseráveis do desenvolvimento web.
• Estrutura de testes e deploy: testes unitários nos frontends, testes de API no backend, testes end-to-end sobre os dois, e um pipeline que roda tudo.

O fio condutor: todo item da lista é algo que você teria construído do mesmo jeito, e todo item é algo que você teria errado sutilmente na primeira vez. Idempotência de webhook, corrida na renovação de sessão e a diferença entre "o pagamento foi aprovado" e "o acesso foi liberado" são o tipo de bug que aparece em produção, à custa de um cliente.

O que você ainda vai ter que construir

Tudo aquilo que é o produto.

Nenhum boilerplate sabe o que a sua aplicação faz. O dashboard é uma casca, a feature de exemplo é um exemplo. É aqui que vai todo o seu tempo restante, e esse é justamente o objetivo.

As decisões de preço continuam sendo suas. O modelo suporta planos e travas por feature; decidir que o plano Pro tem 10.000 chamadas e o gratuito tem 100 é uma decisão de negócio que o código não toma por você.

E-mail transacional, ou seja, recibos, fim de trial e cobrança em atraso, depende de um provedor que você escolhe e de textos que você escreve.

Sua postura de conformidade também é sua: pedidos de exportação e exclusão de dados sob a LGPD e o GDPR, um contrato de tratamento de dados, uma política de cookies que corresponda ao que você de fato carrega. Um template pode deixar os ganchos; ele não fica em conformidade no seu lugar.

As respostas operacionais idem. O que acontece quando um pagamento falha três vezes? Quando alguém faz downgrade no meio do ciclo? Quando alguém pede reembolso depois de usar o produto por 29 dias? O webhook que carrega o evento existe. A política é sua.

O design também. Uma base entrega uma linguagem visual coerente e neutra. Fazer com que ela pareça o seu produto dá trabalho.

O modo de falha honesto

O modo de falha de comprar um boilerplate não é o código ser ruim. É comprar um cuja arquitetura você não quer habitar.

Você está herdando as decisões de outra pessoa sobre framework, banco, provedor de autenticação, estrutura de pastas e alvo de deploy. Se essas decisões batem com as que você tomaria, você economiza semanas. Se não batem, você vai gastar essas mesmas semanas brigando com o template, e teria sido melhor começar do zero.

Então a pergunta de compra não é "tem a feature X?". É se você teria construído desse jeito. Leia a estrutura do repositório e um ou dois módulos reais antes de pagar. Se o código fizer sentido em dez minutos, vai continuar fazendo sentido no sexto mês.

O segundo modo de falha é envelhecer. Uma base é uma foto das versões de dependência do dia em que foi publicada. Veja quando foi a última atualização e se as atualizações estão incluídas, porque um boilerplate que você não consegue atualizar vira dívida técnica com nota fiscal.

Como decidir

Um boilerplate vale a pena quando:

• Você já construiu essa camada antes e sabe com precisão quanto tempo ela leva.
• A stack é a mesma em que você já trabalha.
• O valor do seu produto está no domínio, não na infraestrutura.

Não vale a pena quando:

• Seu produto é infraestrutura, e as escolhas do boilerplate conflitam com ela.
• Você está aprendendo a stack. Vai aprender mais, e mais rápido, num projeto vazio.
• Seus requisitos são incomuns o bastante para que a camada genérica esteja errada de qualquer jeito (multi-tenant com banco por cliente, deploy on-premise, residência de dados regulada).

O número realista

Construir a camada descrita acima direito, não como demo, mas com retentativa de webhook, tratamento de imposto, reembolso, painel administrativo e testes, leva de quatro a oito semanas para uma pessoa experiente. Chamar isso de "um fim de semana com um agente de IA" é marketing; a demo sai num fim de semana, a versão pronta para produção não.

Essa faixa é o valor real de um boilerplate. Tudo o que vem depois é trabalho seu.