Stack para projetos pessoais em 2026: o que eu uso e por quê

Toda vez que começo um projeto pessoal eu paro, respiro e tento não ceder ao instinto de "experimentar uma stack nova". Isso quase sempre custa caro: mais tempo lendo doc, mais bugs em coisa que já estava resolvida, menos tempo entregando. Em 2026, depois de levar três projetos pessoais ao ar — um simulador de previdência, um app PWA de torneios e um app iOS — minha stack convergiu. Esse post é sobre ela: o que escolhi, por quê, e quando eu mesmo quebro a regra.

A régua: tempo até o usuário usar

A pergunta que faço antes de toda escolha é: quanto tempo entre eu abrir o editor e a primeira pessoa real usar isso?

Não é "quão escalável é". Não é "qual a melhor arquitetura". É "quão rápido eu chego no ponto em que alguém clica e me diz 'isso é útil' ou 'isso está ruim'". Em projeto pessoal, todo dia que passa sem feedback é um dia que aumenta a chance de eu desistir.

Essa régua orienta tudo que vem a seguir.

Frontend: Next.js + Tailwind + TypeScript

Para qualquer coisa web, é Next.js. Não porque é a melhor escolha em todos os cenários — não é — mas porque eu já sei onde ficam as armadilhas. App Router, Server Components, generateStaticParams para páginas que viram HTML estático, e metadata por rota para SEO sem preciso pensar.

A combinação que uso:

• Next.js com App Router e geração estática sempre que possível
• TypeScript estrito (strict: true no tsconfig, sem exceções)
• Tailwind CSS com variáveis CSS no :root para tema (light/dark)
• lucide-react para ícones (tree-shakeable, consistentes)
• Vercel para deploy (push no GitHub, deploy em 30 segundos)

Quando começo um projeto, é literalmente npx create-next-app@latest + npm i tailwindcss lucide-react + npm run dev. Em quinze minutos tenho um esqueleto rodando.

O que eu não uso: bibliotecas de componente prontas (shadcn, Material UI, Chakra). Em projeto pessoal, prefiro escrever os 50 componentes que vou usar uma vez do que importar uma dependência que vai me prender em decisões de design feitas por outra pessoa. Tailwind faz isso ser tolerável.

Autenticação: Clerk (quando preciso)

Já tentei rolar autenticação na mão. Já tentei NextAuth. Já tentei Auth0. Em 2026, para projeto pessoal, só uso Clerk.

Razões práticas:

1. Componente pronto que não te dá vergonha. O <SignIn /> do Clerk tem qualidade visual decente, é responsivo e funciona. Em projetos solo isso é ouro.
2. Free tier generoso. 10.000 MAUs no plano gratuito. Mais do que qualquer projeto meu vai precisar antes de eu ter receita pra pagar.
3. Middleware de proteção de rota em uma linha. import { authMiddleware } from "@clerk/nextjs" e pronto.
4. Webhook robusto. Sincroniza users.created, users.updated direto pro meu banco quando preciso.

A exceção é quando o projeto é puramente client-side e não precisa de login (caso do Prev Calc). Aí eu não uso nada — nem login, nem cookies, nem analytics intrusiva. Privacidade vira feature.

Persistência: depende, mas geralmente Redis

Aqui as pessoas se complicam. Para projetos pessoais com pouca estrutura relacional, Redis é absurdamente subutilizado.

No BeachTennis Manager, por exemplo, a estrutura de dados é: usuário tem torneios, torneio tem jogadores, torneio tem partidas, partida tem placar. Parece relacional? Talvez. Mas a verdade é que 95% das queries são "me dá o torneio inteiro X" — eu praticamente nunca preciso de JOINs ou agregações cross-torneio.

Redis com chaves como tournament:{userId}:{tournamentId} resolve isso lindamente:

• Reads são em microssegundos
• Free tier de 256MB no Vercel KV/Upstash dá pra muita coisa
• Sem migrations, sem schemas, só JSON estruturado
• Backup é literalmente KEYS * + GET

Quando eu uso Postgres? Quando preciso de relatórios cross-tenant, agregações pesadas ou full-text search. Para CRUD de produto pessoal, Redis ganha.

Mobile: PWA primeiro, nativo se precisar

Em 2026, a maioria dos meus projetos web roda como PWA. Service Worker via Serwist, manifest.json decente, ícones em todos os tamanhos, e pronto — instalável no Android e iOS.

PWA resolve 90% dos casos de uso "mobile" de um projeto pessoal:

• Instalável na home screen
• Funciona offline (pelo menos páginas estáticas)
• Push notifications (com limitações no iOS)
• Sem App Store, sem revisão, sem 30% de fee

Aí veio o OneMore, e eu me deparei com a outra ponta: algumas APIs são exclusivas do nativo. Live Activity, Dynamic Island, App Intents do Siri, integração com Apple Health. Quando o produto depende dessas integrações, PWA não cobre. Aí é Swift, SwiftUI, SwiftData. E você descobre que dev iOS nativo em 2026 é até divertido — bem mais leve do que era em UIKit.

A regra prática: PWA até a primeira API nativa virar requisito real. Não é antes, não é "porque app é melhor", é só quando dói.

Deploy: Vercel para tudo que é web

Não tenho lealdade religiosa, mas Vercel é onde eu fico. Razões:

1. git push deploya. Branch vira preview URL automaticamente. PR comment com link.
2. Edge Network global sem configurar nada.
3. Free tier que cabe qualquer projeto pessoal.
4. Logs decentes no dashboard.

Quando o projeto cresce, eu reavalio. Mas no t = 0, Vercel + GitHub é o caminho mais curto para o usuário.

O que eu evito por padrão

Toda stack tem escolhas que aparecem mais por tendência do que por necessidade. Em projeto pessoal, prefiro não adotar essas coisas no dia 1 — não porque sejam ruins, mas porque o custo de carregá-las raramente paga em escala pequena. São decisões que reabro depois, quando o problema aparece de verdade:

• Microsserviços. Em projeto solo, monorepo com uma única app cobre na grande maioria dos casos. Microsserviços brilham quando há times independentes ou serviços com SLAs muito diferentes — cenário pouco comum em algo que cabe na cabeça de uma pessoa.
• GraphQL. Para a maior parte dos casos, REST + Server Actions resolvem com bem menos complexidade. Se o produto é uma API pública com muitos consumidores heterogêneos, aí GraphQL paga o preço de entrada.
• State management externo por padrão. Server Components + URL state + useState cobrem a maior parte do que preciso. Adiciono Zustand (ou similar) quando o estado realmente atravessa a árvore e useState vira prop drilling.
• ORM pesado em projeto pequeno. Drizzle quando uso Postgres — sem migrations automáticas, sem mágica. Em time grande mexendo no mesmo schema, a conversa muda.
• Testes E2E desde o dia 1. Em projeto solo, testo as funções puras (cálculo, serialização) e deixo a UI pro QA manual. Quando entra pagamento ou dado crítico, adiciono Playwright sem hesitar.

A régua é simples: cada complexidade adicional precisa pagar pelo custo de carregá-la. "É a tendência" não é justificativa suficiente; "resolve um problema concreto que eu tenho hoje" é.

Ferramentas que mudaram meu fluxo

Algumas coisas que eu adicionei nos últimos 12 meses e não larguei mais:

• Tailwind CSS v4. Configuração via @theme no CSS, sem tailwind.config.js. Bem mais limpo.
• Vercel AI SDK. Quando o projeto precisa de IA, é a interface mais rápida para chegar num MVP.
• Lucide React. Substitui Heroicons sem dor.
• Resend para email. Free tier suficiente, API decente, pronto em cinco minutos.
• Cursor / Claude Code para escrever código. Não como autopilot, mas como par. Pesquisar API alheia, gerar boilerplate de form, refatorar — tudo mais rápido.

A pergunta que importa

A stack não é o produto. É o atalho até o produto. Em projeto pessoal, a métrica certa é "quantos dias entre a ideia e alguém usando". Tudo que aumenta esse número precisa pagar pelo aumento.

Minha stack atual paga porque eu já sei onde ela falha, onde ela brilha e como contornar as armadilhas. Se você está começando, a recomendação não é copiar a minha — é escolher uma stack e ficar nela por três projetos seguidos. Só depois de errar e acertar com ela algumas vezes você entende por que ela é ou não a sua.

Quando ficou óbvio que essa era a minha, eu parei de procurar a próxima.