Construir SaaS B2B virou modelo de negócio da moda no Brasil. Boa razão: receita recorrente, alta margem, escala internacional possível. Mas 90% dos projetos de SaaS quebram não por marketing — por decisão arquitetural errada no início.
Este artigo é o que gostaríamos de ter lido antes de fazer nosso primeiro SaaS. Decisões que parecem técnicas, mas que determinam se você consegue escalar, integrar com clientes corporativos e sobreviver à primeira rodada de auditoria de segurança.
O que é "multi-tenant" sem jargão
Multi-tenant = vários clientes (tenants) usando o mesmo sistema. Cada um vê só os próprios dados. É o modelo padrão de SaaS B2B: uma instância, milhares de empresas.
As 3 abordagens de multi-tenancy
1. Schema único, coluna tenant_id
Todos os clientes compartilham o mesmo banco e as mesmas tabelas, separados por uma coluna `tenant_id` em cada query.
Quando usar: SaaS pequeno e médio, clientes parecidos, sem necessidade de personalização profunda.
Prós: infra simples, baixo custo, deploys rápidos.
Contras: bug de query sem `tenant_id` = vazamento entre clientes. Difícil oferecer customização por cliente.
2. Schema por tenant
Mesmo banco, mas cada cliente em seu schema/namespace.
Quando usar: SaaS médio, clientes com regulamentação leve, necessidade média de isolamento.
Prós: isolamento melhor, backup por cliente.
Contras: custo médio, migrações mais complexas.
3. Banco por tenant
Cada cliente em seu próprio banco.
Quando usar: clientes corporativos, compliance pesado, cliente exige dado em região específica.
Prós: isolamento máximo, possibilita SLA por cliente.
Contras: custo alto, operações complexas, deploy mais delicado.
A escolha certa para 80% dos SaaS brasileiros
Comece com schema único + tenant_id, com middleware obrigatório que injeta o filtro automaticamente. Em escala, evolui para abordagens mais isoladas. Construir do banco-por-cliente cedo demais é overengineering caro.
Pensando em construir um SaaS?
Análise gratuita da sua ideia: arquitetura, custos e plano de validação.
Quero falar com a PragmaSoft →As decisões arquiteturais que pesam
1. Autenticação e SSO desde o dia 1
Cliente corporativo VAI pedir SSO (Google Workspace, Microsoft, Okta). Se você não estruturou desde o início, refazer depois custa caro. Adote uma camada de auth (Clerk, Auth0, FusionAuth, Supabase Auth) desde o dia 1.
2. Multi-tenancy no código, não só no banco
Cada query, cada API, cada job background precisa respeitar `tenant_id`. Use ORM com row-level security ou middleware obrigatório. Vazamento de dado entre clientes é o pior bug possível em SaaS.
3. Audit log desde sempre
Quem fez o quê, quando, em qual cliente. Audit log é obrigatório para SaaS B2B. Implementar depois é dor.
4. Limites por tenant configuráveis
Cliente do plano Pro pode criar 1000 registros, do plano Free pode criar 100. Esse limite tem que ser configurável por banco/feature flag, não hardcoded.
5. Observabilidade por tenant
Métricas, erros e performance precisam ser segmentados por tenant. Quando cliente reclama de "está lento", você precisa saber se é só ele ou todos.
Os custos reais de manter um SaaS
| Item | Custo mensal típico |
|---|---|
| Infra (banco + servidor + CDN) | R$ 2-15 mil |
| Observabilidade (logs, monitoring) | R$ 500-3 mil |
| Auth e segurança | R$ 300-2 mil |
| E-mail transacional | R$ 200-1.500 |
| Manutenção e evolução | R$ 8-40 mil |
Armadilhas que matam SaaS
1. Querer customizar para cada cliente
Cliente grande pede customização. Você cede. Outro cliente grande pede outra. Cede de novo. Em 6 meses, seu código tem 15 variantes. SaaS sustentável diz não, ou usa feature flags.
2. Onboarding manual interminável
Cada cliente novo te toma uma semana de setup? Você não tem SaaS — tem consultoria disfarçada. Invista em onboarding self-service.
3. Pricing baseado em "sentimento"
R$ 99/mês porque "é razoável". Errado. Pricing precisa ser baseado em valor entregue. Cliente que paga pouco também espera pouco.
4. Não medir churn
SaaS é receita recorrente. Sem medir taxa de cancelamento, você não tem ideia se a empresa está crescendo ou afundando.
O que faz SaaS dar certo
- Foco em nicho específico no início (não tente atender "todas as empresas").
- Onboarding rápido (cliente entra e usa em 1 dia).
- Suporte excelente nos primeiros 100 clientes.
- Medição obsessiva de uso e churn.
- Iteração baseada em feedback real, não em "achismo".
Perguntas frequentes
Quanto custa construir o MVP de um SaaS?
R$ 60-180 mil para MVP funcional. Depende muito do escopo. SaaS B2B simples cabe em R$ 90 mil.
Em que linguagem construir?
Pragmática: TypeScript (Next.js/Node) cobre 80% dos casos. Python para SaaS com forte componente de ML. Go para alto desempenho.
Vale começar internacional ou Brasil?
Comece onde está perto. Brasil tem mercado enorme. Internacionalização é fase 2.
Posso usar Supabase ou Firebase?
Para validar e até primeiros 100-500 clientes, sim. Para SaaS sério em escala, geralmente migra para arquitetura própria.
Vamos planejar seu SaaS?
Análise de arquitetura, prazo, custo. Sem compromisso.
Quero falar com a PragmaSoft →
