Next.js + Supabase + Vercel: o tripé enxuto do micro-SaaS brasileiro.

Por que a Labs escolheu essa stack específica, o que descartamos, custos reais em R$ por mês, e onde cada peça começa a pedir substituição.

Toda escolha de stack é uma aposta implícita sobre três coisas: a velocidade de iteração que o fundador precisa, os limites de orçamento, e o tempo que o produto leva para gerar receita. Para o perfil do solo founder brasileiro que a Labs atende — capital próprio, sem rodada no horizonte, primeiro ano construindo enquanto mantém operação paralela — a matemática aperta bem cedo. Stack escolhida errada queima os primeiros 6 meses.

Este texto detalha a escolha feita na casa e os porquês. Não é "a melhor stack do mundo" — é a que funciona no contexto específico. Se seu contexto é diferente, provavelmente a escolha deveria ser outra.

O contexto que define a escolha

Antes da stack: quais são os parâmetros não-negociáveis?

• Solo developer nos primeiros 12-18 meses — stack precisa minimizar alternância de contexto.
• Orçamento < R$ 500/mês no primeiro ano — infraestrutura tem que caber.
• Velocidade de entrega > elegância técnica — não é tempo de experimentar.
• Multi-tenant desde o início — porque os 5 produtos do portfólio vão compartilhar plataforma.
• Integração com IA — modelos locais + Claude como fallback (ver post sobre Ollama + Cloudflare Tunnel).
• TypeScript obrigatório — em casa de solo founder, bugs silenciosos custam o dobro do tempo.

Com essas restrições, três peças se impõem: Next.js, Supabase e Vercel. As razões abaixo.

Next.js 15 (App Router) como framework

Por que Next.js

• SSR + client components no mesmo projeto — sem precisar manter backend separado. Tela pública renderiza do servidor; tela autenticada tem interação client-side. Mesmo código, sem bridges.
• API routes nativas — endpoint de backend fica colado com o front. Não precisa de um Express separado.
• App Router com server actions — operação direta em banco de dados a partir de form submit, sem criar endpoint manual. Reduz 60% do boilerplate típico.
• TypeScript first-class — configuração padrão já vem estruturada.
• Integração com Vercel trivial — deploy por git push, preview automático por branch.

Alternativas consideradas

Remix: ótimo framework, abstrações mais limpas que Next. Descartado porque ecossistema de componentes é menor (shadcn/ui está em Next) e deploy fora da Vercel/Remix Hosting exige decisões extras.

SvelteKit: dev experience excelente, bundle menor. Descartado pelo ecossistema menor de libs prontas em TS — cada decisão "encontro uma lib pronta?" virava pesquisa. Em solo founder, isso custa horas.

Ruby on Rails: framework maduro, dev experience ótima. Descartado porque a Labs já tem TypeScript no restante do ecossistema (IA Gateway em TS, SDK em TS), manter uma stack só reduz troca de contexto.

Django: idem Rails — Python é excelente, mas fragmenta a casa se o resto é TS.

Supabase como banco + auth + storage

Por que Supabase

• PostgreSQL gerenciado — banco "sério" (não SQLite de brinquedo nem NoSQL de aposta), com todas as features: índices, views, triggers, full-text search, row-level security.
• Auth embutido — login com e-mail/senha, OAuth, magic link, tudo pronto. Economiza 1-2 semanas de implementação segura.
• Row-Level Security (RLS) — política de acesso no próprio banco, multi-tenant seguro sem inventar middleware custom.
• Storage de arquivos — bucket S3 compatible com integração de segurança amarrada ao auth. Upload de PDF direto do front.
• Realtime opcional — websocket para notificações quando precisar.
• Tipos gerados automaticamente — supabase gen types produz types TS a partir do schema real. Sincronia entre back e front sem trabalho manual.

Alternativas consideradas

PostgreSQL cru em servidor próprio (Hetzner, DigitalOcean): controle total, custo baixo. Descartado porque solo founder não tem tempo para gerenciar backups, upgrades de versão, SSL, failover. Supabase resolve tudo por US$ 25/mês no Pro.

Firebase: auth + firestore + storage em único pacote. Descartado porque Firestore é NoSQL e Labs precisa de queries relacionais complexas (joins, aggregations, views). Firestore vira dor logo no primeiro relatório.

Neon + auth próprio: Neon é excelente Postgres serverless, preço competitivo. Descartado porque exigiria implementar auth separado (Lucia, NextAuth, Clerk) — +1 dependência, +1 ponto de falha.

PlanetScale: MySQL serverless. Descartado pela ausência de foreign keys (modelo consistente interno difícil) e pelo MySQL ter menos features que PG.

Vercel como deploy + edge

Por que Vercel

• Deploy por git push — commit → deploy automatico em segundos. Preview branches automáticos.
• Edge Functions + Edge Config — código roda perto do usuário, latência baixa.
• Serverless functions nativas — todas as API routes do Next.js viram funções serverless.
• Logs + observability embutidos — dashboard com latência, erros, tráfego sem Datadog.
• Integração com Supabase via secrets — env vars que sincronizam entre preview e production com 1 clique.
• Plano Hobby gratuito — até certo limite de bandwidth/compute. Suficiente para os primeiros 6 meses de cada produto.

Alternativas consideradas

Netlify: concorrente direto de Vercel. Descartado porque Next.js roda melhor na plataforma que o criou (Vercel é mantenedora do Next).

AWS Amplify: robusto, completo. Descartado pela complexidade de setup — hora inicial em config de IAM + CloudFormation custa muito em solo founder.

Railway + VPS: dev experience legal, custo previsível. Descartado porque perde o deploy-por-push simples do Vercel + preview automático.

Custos reais em R$ por mês (Labs em 2026)

Valores reais que a Labs paga hoje, considerando os 5 produtos do portfólio + infraestrutura compartilhada:

Isso não inclui IA Local (já pago com a GPU do desktop do fundador) nem hardware já existente. Se contar GPU de terceiros, custo sobe mas ainda cabe em R$ 500/mês.

Setup inicial em 30 minutos

Do zero a um produto rodando em branco, com auth e banco conectados:

# 1. Criar app Next.js com TypeScript
npx create-next-app@latest meu-produto --typescript --tailwind --app

cd meu-produto

# 2. Instalar dependências Supabase
npm install @supabase/supabase-js @supabase/ssr

# 3. Criar conta Supabase (https://supabase.com) e novo projeto
# 4. Pegar SUPABASE_URL + SUPABASE_ANON_KEY + SUPABASE_SERVICE_ROLE

# 5. Criar .env.local
cat > .env.local << EOF
NEXT_PUBLIC_SUPABASE_URL=https://xxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJxxx...
SUPABASE_SERVICE_ROLE_KEY=eyJxxx...
EOF

# 6. Criar cliente Supabase em lib/supabase/
# (código em 2 arquivos: browser.ts e server.ts — padrão do SSR helper)

# 7. Instalar shadcn/ui (ecossistema de componentes)
npx shadcn@latest init
npx shadcn@latest add button input card

# 8. Conectar ao GitHub + Vercel
git init
git remote add origin git@github.com:xxx/meu-produto.git
# No Vercel: import project, connect repo, paste env vars, deploy

Resultado: app rodando em meu-produto.vercel.app com banco, auth e CDN globais. Trinta minutos reais, não marketing.

Onde cada peça começa a pedir substituição

Stack enxuta tem limites. Saber onde eles estão evita dor futura.

Next.js

Dor aparece quando o produto precisa de workloads de longa duração que não cabem em serverless (ex: processamento de vídeo, render 3D, batch de 10 min). Nesse caso, separar um worker dedicado (Node + BullMQ em Railway ou VPS) e manter Next.js como front + API leve. Não trocar Next inteiro — só extrair o worker.

Supabase

Três limites possíveis:

• Escala de banco — acima de ~1M de registros em tabelas críticas, custo do plano Pro sobe rápido. Quando chegar ali, considerar self-host de PG em Hetzner (R$ 100-200/mês) e migrar só o banco. Auth + Storage ficam no Supabase (ou se migra tudo de uma vez quando tiver pessoa dedicada).
• Auth customizado — se precisar de fluxo muito específico (ex: biometria, SSO corporativo complexo), Supabase Auth pode não cobrir. Solução: manter Supabase + adicionar Clerk ou Auth0 em camada superior. Raro.
• Realtime pesado — websocket do Supabase é ótimo até algumas centenas de conexões simultâneas. Acima disso, considerar Pusher ou Ably para eventos em tempo real.

Vercel

Dois limites:

• Custo de bandwidth em escala — se produto virar conteúdo denso servido para muita gente, bandwidth da Vercel fica caro. Solução: mover assets (imagens, vídeos) para S3 + CloudFront ou Cloudflare R2. Next.js continua na Vercel.
• Timeout de serverless (10s no Hobby, 60s no Pro) — tarefas longas precisam ir para worker dedicado (mesmo caso do Next acima).

Em nenhum dos casos acima a stack é "trocada". É extendida — novos componentes somam aos existentes. Isso reduz o risco de reescrita — problema comum em scale-ups que trocaram stack cedo demais.

O que não está nesta stack e faz diferença

Dois componentes adicionais que a Labs usa fora desse tripé mas que vale mencionar:

Cloudflare Workers — para o IA Gateway (roteamento entre Ollama local + Haiku). Custo zero no plano Free. Setup em uma tarde.

Resend — envio de e-mail transacional. US$ 0 até 3.000 e-mails/mês, depois US$ 20. Substitui SendGrid (mais caro + complexo) e SMTP próprio (dor).

A escolha embutida: stack ≠ startup

O maior risco de escolher stack hype é que startup não é só a stack. Stack escolhida "porque todo mundo usa no Twitter" vira pedra se o ecossistema local não acompanha (libs em português, fornecedor de NF-e integrado, pagamento via Pix).

Next + Supabase + Vercel funciona no Brasil em 2026 porque: (a) a maior comunidade de TS/React está aqui; (b) há devs juniores disponíveis que já conhecem; (c) fornecedores locais de NF-e, Pix, boleto, anti-fraude têm SDKs em Node; (d) suporte em inglês é viável para o fundador que lê documentação.

Se você é desenvolvedor brasileiro com capital próprio construindo micro-SaaS, essa escolha cabe bem. Se seu contexto é diferente — equipe grande, muito budget, produto muito específico — a análise muda. O tripé aqui documentado não é dogma; é o que a Labs escolheu depois de descartar as alternativas. O método de escolher é o que importa mais que a escolha em si.

Publicado em 2026-04-10. Mais detalhes sobre setup, CI/CD e deploy no e-book Stack Enxuta Brasileira (biblioteca — em construção).
Receba os textos técnicos por e-mail: assine a newsletter →