De ideia a produto: a stack que uso para construir rápido como engenheiro solo
Construir rápido sozinho não é sobre usar menos ferramentas — é sobre escolher as certas e não mudar de ideia no meio do caminho.
Toda vez que alguém me pergunta sobre stack para projeto solo, a resposta real é: depende menos da stack e mais de você não mudar de stack no meio do projeto.
Dito isso, aqui está o que eu uso e por quê.
Frontend: Next.js com output estático quando possível.
Next.js porque eu não quero pensar em bundler, routing, SSR/SSG trade-offs, ou configuração de build. Tudo isso vem resolvido. Quando o produto é conteúdo público sem necessidade de autenticação pesada ou dados em tempo real, export estático vai para GitHub Pages — zero infraestrutura de servidor para gerenciar.
Tailwind v4 porque eu não quero CSS customizado. Quero classes utilitárias que compilam bem e são previsíveis. Dark theme por padrão porque é o que eu prefiro olhar quando trabalho.
TypeScript strict porque bugs descobertos em compile time são grátis. Bugs descobertos em produção com usuário real são caros.
Backend/dados: Supabase.
Banco de dados, autenticação, e storage em uma instância gerenciada. Para produto solo, o tempo economizado não gerenciando Postgres, não configurando auth, não pensando em backup — vai direto para construir a feature que o usuário vê.
O trade-off: você não controla a infra. Para produto solo em fase inicial, esse trade-off é correto. Quando o produto escalar a ponto de justificar infra própria, você vai ter recursos para migrar.
Deploy: GitHub Actions para CI, GitHub Pages para estático, Vercel para produtos que precisam de API routes.
GitHub Pages é gratuito para repositórios públicos. Para sites de conteúdo, é suficiente. Para produtos com backend, Vercel tem o plano mais generoso que encontrei para hobby projects.
IA no workflow: Claude Code como par.
Não como ferramenta separada — como parte do editor. Descrevo o que preciso, itero, reviso, aceito ou rejeito. O ganho não é velocidade de digitação — é conseguir avançar em áreas onde meu conhecimento é superficial sem travar.
O que não uso mais:
Docker em desenvolvimento local para projeto solo. O overhead de manter Dockerfile e docker-compose para uma pessoa trabalhando em uma máquina não compensa. Docker fica para CI e para contextos onde preciso garantir paridade com produção.
ORMs complexos. Supabase client é suficiente para a maioria dos casos. Quando preciso de query mais complexa, escrevo SQL.
Monorepo para projeto solo. Um repositório por produto. Simples, rastreável, sem toolchain de workspace para gerenciar.
O que importa mais do que stack:
Começar com o mínimo que valida a hipótese. A stack serve o produto — não o contrário. Se você está escolhendo stack em vez de construir o produto, você está procrastinando com aparência de produtividade.
Essa semana: se você tem um projeto parado "esperando a stack certa", escreva em 15 minutos qual seria a stack mais simples possível para ter algo testável com usuário real em 2 semanas. Use essa.