Toda discussão sobre stack para SaaS começa com opiniões fortes e termina com pouco critério prático. 'Use Go, é mais rápido.' 'Node escala melhor.' '.NET é coisa de enterprise.' 'Python não aguenta produção.' Essas afirmações têm alguma verdade em contextos muito específicos e são inúteis para a maioria das decisões reais. O que move o ponteiro não é o benchmark de throughput que você encontrou no Hacker News — é o conjunto de trade-offs que você está disposto a aceitar dado o seu contexto: o time que você tem agora, o prazo que você não pode estourar, e o tipo de cliente que você quer fechar nos próximos 12 meses. Este post é sobre como pensar essa decisão de forma estruturada.

Por que a escolha de stack importa mais no SaaS do que em outros contextos

Em um projeto de software tradicional — sistema interno, aplicação para cliente único, consultoria com escopo fechado — uma escolha de stack equivocada tem custo limitado. Você termina o projeto, ele vai para produção, e as consequências ficam contidas.

Em SaaS, a stack é a fundação sobre a qual você vai construir por anos. Três consequências diretas de uma escolha ruim:

Custo de contratação. Se você escolhe uma tecnologia com mercado de trabalho pequeno no Brasil, cada nova contratação vai ser mais cara e mais lenta. Isso parece irrelevante quando o time tem duas pessoas — e vira um gargalo real quando você precisa crescer rápido.

Dívida técnica acelerada. Stacks escolhidas por familiaridade do fundador sem considerar os requisitos do produto (multi-tenancy, billing recorrente, integrações B2B) tendem a acumular gambiarras. Cada gambiarra cria fricção para as próximas features.

Custo de mudança. Migrar a stack de um SaaS em produção com clientes é diferente de migrar um projeto parado. Você precisa manter o que existe funcionando enquanto reescreve — e isso, na prática, significa dobrar o esforço de desenvolvimento por um período que invariavelmente é maior do que o planejado.

Os critérios que realmente importam — e a ordem certa de avaliá-los

Antes de comparar linguagens e frameworks, defina os critérios de decisão pelo seu contexto. Aqui estão os que mais afetam SaaS B2B:

1. Velocidade até o primeiro cliente pagante

O critério mais importante no early-stage é chegar ao mercado antes de ficar sem dinheiro ou sem motivação. A melhor stack para isso é a que o time domina hoje — não a que parece mais elegante no papel. Um produto em produção com stack imperfeita é infinitamente mais valioso do que uma arquitetura ideal que ainda está no Notion.

2. Requisitos do produto que a stack precisa suportar bem

Para SaaS B2B, alguns requisitos aparecem cedo e são custosos de implementar em stacks que não têm bom suporte:

• Multi-tenancy com isolamento de dados
• Autenticação federada (SSO via SAML/OIDC)
• Integrações com sistemas corporativos (ERPs, CRMs, APIs de terceiros)
• Billing recorrente com webhooks e idempotência
• Relatórios e exportações com volume razoável de dados

Avalie se a stack que você está considerando tem bibliotecas maduras para esses requisitos — ou se você vai precisar construir do zero.

3. Mercado de trabalho e custo de contratação no Brasil

Esse critério é subestimado até o momento em que você precisa contratar e descobre que candidatos competentes para a stack escolhida são raros ou caros demais para o momento da empresa.

4. Custo de operação em escala inicial

Não estamos falando de escala de Google — estamos falando de 50 a 500 tenants, que é onde a maioria dos SaaS B2B vai passar os primeiros 2-3 anos. Stacks com runtime pesado (JVM, por exemplo) têm custo de infraestrutura maior em escala baixa. Stacks serverless têm cold start que pode incomodar dependendo do padrão de uso.

5. Custo de mudança se a aposta estiver errada

Algumas decisões são reversíveis com custo razoável — troca de banco de dados relacional, mudança de framework de frontend. Outras são praticamente irreversíveis no curto prazo — linguagem do backend, modelo de dados fundamental, escolha entre monolito e microsserviços. Avalie cada decisão pelo custo de desfazê-la, não só pelo custo de implementá-la.

Backend: .NET Core, Node.js, e quando cada um faz sentido

Para SaaS B2B com requisitos de domínio complexo — multi-tenancy, billing, integrações corporativas, relatórios — .NET Core é uma escolha sólida por razões práticas:

• Tipagem forte que reduz bugs em domínio complexo sem abrir mão de produtividade
• Entity Framework Core com suporte maduro a multi-tenancy via query filters
• Ecossistema consolidado para autenticação, autorização, workers em background, filas
• Performance suficiente para a escala de qualquer SaaS B2B no early e mid-stage
• Mercado de trabalho relevante no Brasil, especialmente em empresas com histórico .NET
• Gratuito e open source desde o .NET Core, sem licenciamento

Não é a única escolha válida. Node.js com TypeScript faz sentido quando:

• O time tem expertise sólida em JavaScript/TypeScript e pouca experiência com .NET
• O produto tem requisitos de I/O intenso e baixa lógica de domínio (proxy, agregador de APIs)
• Você quer compartilhar código de validação e tipos entre frontend Next.js e backend

O que tende a criar problemas em SaaS B2B:

• Python como backend principal: produtivo para protótipos, mas tipagem fraca e performance em I/O assíncrono criam fricção quando o domínio cresce
• Microsserviços desde o dia um: o overhead operacional de manter múltiplos serviços em produção consome capacidade de engenharia que deveria estar em produto; comece com um monolito bem organizado
• Stack completamente nova para o time: aprender uma nova stack enquanto constrói o produto atrasa ambos

Frontend: Next.js como escolha padrão para SaaS B2B

Para SaaS B2B, Next.js é atualmente a escolha com melhor custo-benefício para a maioria dos casos. Os motivos:

• App Router com Server Components reduz a quantidade de JavaScript enviado para o cliente — importante para dashboards com muitos dados
• SSR nativo resolve SEO para páginas de marketing no mesmo repositório que a aplicação
• Middleware de autenticação e tenant resolution com código relativamente simples
• Ecossistema React maduro com bibliotecas para praticamente qualquer necessidade de UI
• Mercado de trabalho amplo no Brasil

Alternativas que fazem sentido em contextos específicos:

• SvelteKit: bundle menor, menos boilerplate, boa opção se o time já conhece Svelte. Mercado de trabalho menor.
• Remix: roteamento e data loading opinado, bom para apps com muitos formulários e mutations. Está convergindo com Next.js em muitos aspectos.
• Vue.js com Nuxt: válido se o time tem background Vue. Menos adotado em B2B enterprise no Brasil.

O que evitar no contexto de SaaS B2B:

• SPA puro (Create React App, Vite sem SSR): SEO problemático para páginas de marketing, sem Server Components, sem middleware de autenticação nativo
• Frameworks de nicho sem comunidade ativa: o custo de encontrar respostas para problemas específicos e contratar fica alto

Banco de dados: PostgreSQL e quando considerar alternativas

PostgreSQL é o banco relacional padrão para SaaS B2B por boas razões: ACID compliance, JSON nativo para dados semi-estruturados, extensões para full-text search, suporte a schemas para multi-tenancy, e operação gerenciada disponível em todos os providers de cloud relevantes.

O que o PostgreSQL resolve bem no SaaS B2B:

• Isolamento de tenants via schema ou tenant_id com filtros
• Transações que garantem consistência em operações de billing
• Queries analíticas para relatórios sem precisar de um banco separado até volumes altos
• JSON para dados de configuração por tenant que variam entre clientes

Quando considerar complementar com outros bancos:

• Redis: cache de sessão, rate limiting por tenant, pub/sub para notificações em tempo real. Não substitui o PostgreSQL — complementa.
• Elasticsearch / OpenSearch: quando o produto precisa de busca textual avançada com relevância — não para queries simples que o PostgreSQL resolve com ILIKE ou full-text search nativo.
• Banco de dados analítico separado (BigQuery, Redshift): quando os relatórios do produto começam a impactar a performance das operações transacionais. Raramente necessário antes de centenas de tenants com volume alto.

O que evitar:

• MongoDB como banco principal em SaaS com domínio relacional: a flexibilidade de schema que parece vantagem no começo vira bagunça de dados quando o produto cresce
• Múltiplos bancos de dados diferentes desde o início: cada banco adicional é um sistema a mais para operar, monitorar e fazer backup

Infraestrutura: o que você realmente precisa no early-stage

A stack de infraestrutura ideal para um SaaS B2B early-stage é a mais simples possível que suporta o produto funcionar em produção com segurança. Isso raramente é Kubernetes.

Um setup que funciona para os primeiros 12-18 meses e escala além disso:

Compute: AWS ECS Fargate para containers, sem precisar gerenciar servidores. Dois serviços: a API e o Worker de background. Auto-scaling configurado mas não necessariamente ativo desde o dia um.

Banco de dados: RDS PostgreSQL com Multi-AZ desabilitado no início (custo) e habilitado quando a receita justificar. Backups automáticos habilitados desde o primeiro dia.

Fila: SQS para comunicação assíncrona entre API e Worker. Simples de operar, custo baixíssimo em volume pequeno.

Cache: ElastiCache Redis se você precisar de cache distribuído; se estiver com uma única instância da API, cache em memória é suficiente.

CI/CD: GitHub Actions com deploy automático para staging em cada PR e deploy para produção em merge na branch principal. Sem isso, o custo de deploy manual vai consumir tempo que deveria ir para o produto.

O que não precisa estar no MVP de infraestrutura:

• Kubernetes (custo de operação desproporcional ao benefício no early-stage)
• Microsserviços (mesmo motivo)
• CDN personalizado (CloudFront padrão do AWS é suficiente)
• Múltiplas regiões (quando a receita de clientes que exigem isso justificar)

A matriz de decisão: aplicando os critérios ao seu contexto

Com os critérios definidos, a forma de aplicá-los é fazer as perguntas na ordem certa para o seu contexto:

Passo 1 — O time domina essa stack?

Se sim, o ônus da prova é sobre mudar, não sobre manter. Uma stack dominada pelo time entrega mais rápido e com menos bugs do que uma stack nova, mesmo que a nova seja objetivamente melhor em benchmarks.

Passo 2 — Essa stack tem bibliotecas maduras para os requisitos de SaaS B2B?

Multi-tenancy, autenticação, billing, filas. Se algum desses requisitos vai exigir construção do zero na stack escolhida, some esse custo ao cronograma.

Passo 3 — Você consegue contratar para essa stack no Brasil em 6 meses?

Pesquise vagas abertas para a stack no LinkedIn Brasil. Se tem menos de 50 vagas abertas hoje, o mercado é pequeno. Não inviabiliza a escolha — mas aumenta o custo e o prazo de contratação.

Passo 4 — Quanto custa essa stack para operar com 100 tenants?

Faça a conta com os valores atuais dos serviços que você vai usar. RDS + ECS + SQS para uma aplicação modesta fica entre R$ 800 e R$ 2.000/mês — razoável para early-stage com receita crescendo.

Passo 5 — O que você vai precisar reescrever quando crescer?

Não há resposta perfeita aqui. Toda stack vai exigir alguma refatoração quando o produto crescer. A pergunta é se a refatoração vai ser incremental (adicionar um serviço, otimizar queries, adicionar cache) ou estrutural (mudar modelo de dados, reescrever o backend em outra linguagem). Escolhas que levam ao segundo tipo custam caro.

Se depois dessas cinco perguntas você ainda não tem uma resposta clara, o empate técnico é um sinal de que qualquer das opções em consideração é aceitável — e o critério de desempate deve ser a familiaridade do time, não a opinião do blog que você leu esta semana.

---

Se você está no momento de definir a stack do seu SaaS e quer uma opinião técnica com contexto do mercado brasileiro — sem benchmark de laboratório, com análise do seu caso específico — fala com a Logik Digital.

Conversar com a Logik Digital