Stack Otom 2026: como decidimos entre Next.js, Vite e React Native

Em 2026, ninguém mais ganha pontos por escolher stack moderna. Todo mundo sabe Next.js, todo mundo sabe React Native, todo mundo já ouviu falar de Vite. O que faz diferença pro cliente é quando usar o quê, e os motivos por trás da decisão.

Esse texto mostra como decidimos na Otom em 3 casos comuns. Não é "esse é o melhor framework de 2026". É: dado um problema X, com restrição Y e equipe Z, qual stack diminui dor.

Caso 1 · Site institucional + landing de campanha

Stack escolhida: Next.js 15 (App Router) + Tailwind + Vercel.

Por quê:

• SEO técnico: SSR/SSG nativo, metadata API, sitemap dinâmico, robots por rota. Vite SPA também faz, mas dá mais trabalho.
• ISR pra blog: regenera só a página que mudou. Mantém site rápido com 200+ posts.
• Edge functions: roteamento por geografia, A/B test no servidor, redirect inteligente.
• Vercel: deploy contínuo, preview por PR, analytics builtin. Outro provedor funciona, mas Vercel + Next reduz fricção.

O que evitamos:

• Server Components em tudo. Onde precisa de interação rápida (carrossel, accordion), client component. Sem dogma.
• tRPC pra site público. Site institucional pega dado de CMS ou estático. tRPC vira complexidade sem retorno.

Caso 2 · Dashboard interno (CRM, ERP, painel ops)

Stack escolhida: Vite + React 19 + Tailwind + shadcn/ui + NestJS API + Postgres + Prisma.

Por quê não Next:

• Dashboard interno não precisa de SEO. SSR pesa o build, complica auth, e o usuário tá logado.
• SPA é mais rápida pro fluxo de tela. Carrega 1 vez, navega zero round-trip. Em dashboard isso vira UX visível.
• Hot reload de Vite é absurdamente mais rápido que o do Next. Em ciclo de iteração com cliente, isso paga.

Por quê NestJS no back:

• Estrutura opinada, módulo, controller, service, DTO. Time grande achar arquivo sem ler README.
• DI nativa, fila com BullMQ, validação com class-validator, swagger automático. Pacote completo.
• Compatível com Prisma, TypeORM, raw SQL. Não te prende.

O que evitamos:

• Microservices. Monolito modular resolve quase tudo até 30 desenvolvedores. Microservice é overhead disfarçado de boa prática.
• GraphQL. REST + tipos compartilhados (via zod ou Prisma type) entrega quase a mesma DX com 1/3 da complexidade.

Caso 3 · App de cliente (iOS + Android)

Stack escolhida: React Native + Expo + EAS Build.

Por quê não Flutter:

• Time React já existe, reuso de conhecimento e código.
• Ecossistema npm é maior. Pra integração com SDK específico (analytics, push, biometria), tem lib pronta.
• Expo cobre 90% dos casos sem ejetar. Build na nuvem, OTA, push, biometria, deep link tudo nativo.

Quando NÃO usaríamos React Native:

• App de jogo ou animação complexa (Flutter ou nativo puro)
• App com integração nativa muito pesada (camera, AR, ML on-device), depende, mas tendência a nativo
• App que vai usar muito hardware específico (NFC mais profundo, sensores customizados)

O que mudou de 2024 pra 2026

• Next.js 15: Server Actions amadureceu, vale a pena pra forms simples. Caching ficou previsível depois do 14.2.
• React 19: hooks novos (use, useActionState) simplificam padrões que antes precisavam de lib externa.
• shadcn/ui: virou padrão pra dashboard interno. Não é lib, é template, você dono do código, sem dependência.
• Bun: testamos em projeto novo. Ainda não substitui Node em produção pra todos os casos, mas em scripts de build e CLIs ganhou espaço.
• Drizzle ORM: subiu. Pra projeto novo, comparamos com Prisma caso a caso. Drizzle ganha em controle de SQL e perf; Prisma ganha em DX e migrations.

O que NÃO usamos em produção (e por quê)

• Remix: bom framework, mas perdeu energia. Next domina ecossistema, então é menos arrisco.
• SvelteKit: ótimo. Não é stack que cliente conhece pra contratar próximo dev.
• Astro: usamos pra blog estático puro. Pra site com app sections, voltamos pra Next.
• Deno Deploy: cool. Edge inferior à Cloudflare/Vercel em prática.

Resumo de 3 linhas

Site público com SEO: Next.js. Dashboard interno: Vite + Nest. App mobile: React Native + Expo. Tudo TypeScript estrito. Tudo com tipos compartilhados back/front. Tudo com observabilidade (Sentry + GA4 + log estruturado) desde o dia 1, porque debugar produção sem isso é roleta russa.