Para agências e freelancers
A base multi-tenant que você entrega a cada cliente
sem reconstruir
Workspace isolation, permissões por papel, billing por organização, API keys — as partes que são uma semana de trabalho cada uma, já construídas e testadas. Entregue mais rápido, cobre o mesmo.
Você cobra os 30% únicos do cliente, não os 70% reutilizáveis
Um MVP de SaaS B2B costuma ser $5k–$15k de tempo de dev (40–120 horas a $50–$150/hora). A maior parte reconstrói os mesmos 70%: auth, times, papéis, billing, admin. Entregue isso de uma base testada e suas horas faturáveis vão pra onde devem — os 30% únicos do cliente. A base se paga no primeiro projeto.
Por que as agências montam uma base reutilizável — nas palavras delas
Uma semana de trabalho cada uma
"workspace isolation, role-based permissions, billing per organization, custom domains, audit logs — each piece is a week of work." — RovaAI, Indie Hackers
Por isso reutilizam a própria
"For the common functionalities (login, signup, admin panel, user panel) I used boilerplate from my other projects." — ideastosaas, Indie Hackers
Só auth é um mês
"building and testing a full featured authentication system takes at least a month to do properly." — kylegawley, Indie Hackers
Multi-tenancy de verdade, não uma tabela users com uma coluna role
Organizações, membros, convites, RBAC, billing por org e API keys. Por baixo, um tenant-isolation guard — repositórios org-scoped mais um query guard do Prisma — faz uma leitura cross-organização devolver 404, não os dados de outro. É a peça genuinamente difícil de acertar, já acertada.
1 GET /api/orgs/acme/projects/42
2 session.org = "globex" // outra org
3
4 → 404 Not Found
5 // o repo org-scoped nunca devolve
6 // a linha de outro tenant.
Nunca entregue insegurança com o nome do seu cliente em cima
O passivo é real
Um scan público encontrou 303 endpoints expostos em 170 sites vibe-coded vazando dados pessoais, de pagamento e API keys. Pra trabalho entregue sob a marca de um cliente, isso é risco reputacional e legal.
As partes perigosas estão endurecidas
Auth, RBAC e tenant isolation aqui são DDD-layered e testados no CI — não código de segurança que parece plausível com falhas sutis que um agente deixou.
Aguenta uma segunda olhada
Contratos OpenAPI tipados, um event bus com outbox audit-friendly e observabilidade OTel/Sentry fazem o trabalho aguentar uma revisão técnica, não só um demo.
A resposta pra "a maioria dos starter kits acaba reconstruída"
"Most of the business who use starter kit eventually end up rebuilding software from scratch." (sachingk, Indie Hackers) Essa é a reclamação mais alta da categoria — e é uma reclamação sobre starters spaghetti, não sobre arquitetura. Fronteiras DDD, testes e contratos tipados são a resposta direta: uma base que cresce cliente após cliente em vez de ir pro lixo no terceiro.
Ganhe mais projetos, fique com mais margem
Feche os projetos latinos que os kits Stripe-only perdem
MercadoPago nativo mais docs reais em EN/ES/PT deixam você pegar clientes brasileiros, argentinos e mexicanos que os kits Stripe-first não conseguem atender.
Entrega sob a marca do seu cliente
Você é dono do código por inteiro, então o produto que entrega leva o nome do seu cliente — nada força um badge da UseDeploy no que você entrega.
Uma base viva, não um snapshot congelado
Uma ferramenta de sync upstream traz as melhorias do boilerplate pros seus projetos sem um merge completo — então a fundação continua melhorando em vez de envelhecer.
FAQ de agências e freelancers
Posso usar em múltiplos projetos de clientes?+
É mesmo diferente de um starter kit descartável?+
Consigo pegar clientes da América Latina com isso?+
Herdei um app vibe-coded quebrado. Consigo aterrissar aqui?+
Entregue mais, reconstrua menos.
Entregue os 70% reutilizáveis de uma base testada e fature suas horas onde importam — os 30% únicos do cliente.