Por que o Next.js é nossa stack padrão (e quando não o escolhemos)

Se você analisar os projetos do portfólio da Pair Programming, vai notar um padrão claro: quase todos compartilham a mesma stack. Next.js como framework, React para a interface, Supabase como base de dados e backend, Tailwind e shadcn/ui para estilos. Não é por acaso, nem preguiça. É uma decisão de arquitetura bem pensada. Vamos aos motivos.

Os critérios: o que valorizamos em uma stack

Antes de defender a stack, os critérios que usamos para escolhê-la:

1. Tempo de entrega: capacidade de colocar o produto no ar rapidamente.
2. Manutenibilidade: que, em 18 meses, outro desenvolvedor consiga entender e modificar sem dores de cabeça.
3. Custo operacional: sem piso mensal obrigatório alto.
4. Performance percebida: que o usuário final sinta o produto rápido.
5. SEO amigável: essencial para produtos públicos.
6. Ecosistema: quando um problema aparece, que já exista uma solução pronta.

Por que o Next.js

Ele atende aos 6 critérios melhor do que qualquer outro framework atualmente:

Renderização híbrida. O Next.js permite que cada página decida se será renderizada no servidor (SSR), gerada estaticamente no build (SSG) ou totalmente no cliente (CSR). Isso é revolucionário: a homepage e landing pages são estáticas (super rápidas, SEO perfeito), o dashboard interno usa SSR com autenticação, e os componentes muito interativos vão para o cliente. Tudo em uma única codebase, com modos distintos por página.

App Router com Server Components. Desde o Next.js 13+ com o App Router, os componentes são server por padrão. Isso significa menos JavaScript no cliente, melhor performance e a possibilidade de fazer queries no banco diretamente no componente, sem precisar criar uma API.

Imagens, fontes e scripts otimizados de fábrica. O next/image faz lazy loading, srcset e conversão automática para formatos modernos. O next/font carrega fontes sem shift de layout. O next/script controla a ordem de execução. Coisas que, em outra stack, levariam semanas de otimização, no Next.js vêm de graça.

SEO de primeira linha. A estrutura do framework é pensada para sites indexáveis: API de metadados por página, sitemap.ts dinâmico, robots.ts, rewrites e redirects na configuração, dados estruturados fáceis. Fizemos SEO programático com centenas de páginas indexáveis sem brigar com o framework.

Deploy no Vercel. Zero configuração, rede edge global, escalabilidade automática, preview por pull request. O custo começa em USD 0 e só aumenta quando o projeto de fato gera tráfego real.

Por que o Supabase como parceiro

O React sozinho não é suficiente: você precisa de dados, autenticação, armazenamento. As opções são: construir tudo do zero (lento), AWS desde o início (complexo) ou usar um BaaS (backend-as-a-service). Entre os BaaS, o Supabase se destaca por:

• Postgres real, não uma pseudo-base como o Firebase. SQL, relacionamentos, transações, tudo que você espera.
• Autenticação completa incluída, com magic links, OAuth e logins sociais.
• Row Level Security no nível do banco de dados, crítico para multi-tenant.
• Storage para arquivos com CDN.
• Open source, podendo ser auto-hospedado se necessário.
• pgvector disponível para embeddings e IA (usamos no Tontin).
• Edge functions para lógica server-side customizada.

A stack em ação: 4 projetos diferentes

O melhor da stack é que ela serve para contextos muito distintos sem conflitos:

Meu Seguro de Auto: produto público, alto tráfego SEO, integrações com seguradoras. O Next.js renderiza páginas programáticas otimizadas para o Google, o Supabase armazena cotações e leads. Cada página pesa pouco e carrega rápido no mobile (onde 80% dos usuários fazem cotações).

La Carolina: CRM interno, não precisa de SEO mas sim de autenticação robusta, multi-tenant e performance em operações complexas. Mesma stack, abordagem diferente: server components para data fetching, RLS para isolamento, sincronização bidirecional com o Google Calendar via edge functions.

Tontin: plataforma com IA pesada, embeddings, múltiplos LLMs em cadeia de fallback. O Next.js orquestra o frontend e a API, o Supabase armazena conversas e embeddings com pgvector, edge functions gerenciam chamadas aos modelos.

Zweifel Capital: site premium para family office em Londres/Buenos Aires/Nassau. Estáticos puros, design cuidadoso, multi-idioma. Next.js + Tailwind, deploy estático no Vercel. Zero banco de dados, zero backend, tudo edge. Outra face da mesma stack.

Quando NÃO escolhemos o Next.js

Há casos em que outra opção é melhor:

• Backend pesado sem UI: se o que você precisa é de uma API pura sem frontend, Fastify ou NestJS são melhores.
• Apps mobile nativos: React Native é outra história. E se precisar de performance nativa real, Flutter ou Swift/Kotlin diretos são a escolha.
• Aplicações realtime complexas: para algo como um editor colaborativo tipo Figma ou um jogo multiplayer, você precisa de mais peso no cliente com stacks como Vue + Pinia + WebRTC ou equivalente.
• Sites extremamente simples: uma landing page de um único produto pode ser feita no Astro ou até em HTML/CSS puro. O Next.js é overkill.

O argumento mais forte: o tédio (positivo)

O melhor de escolher uma stack consistente é o tédio positivo. Não estamos reinventando a roda em cada projeto, avaliando alternativas, debatendo. A equipe conhece as ferramentas, os padrões são reutilizados, os problemas comuns já estão resolvidos. Isso libera energia para resolver o problema do cliente, que é o que realmente importa.

Conclusão

Next.js + React + Supabase + Tailwind cobre quase todo o espectro de aplicações web modernas. Não é o melhor para tudo, mas é suficientemente bom para quase tudo e excepcional para o que mais fazemos. Essa combinação de versatilidade e maturidade é o que a torna a escolha padrão hoje.

Se você está decidindo a stack para um novo projeto ou avaliando migrar um existente, fale conosco. Ajudamos a pensar a decisão técnica considerando seu produto, sua equipe e seu timeline.

---

Por Esteban Aleart, Fundador & Lead Engineer da Pair Programming.