Seu primeiro projeto de vibecoding: um checklist de 12 passos antes de abrir o Cursor

Seu primeiro projeto de vibecoding vai começar com a pior decisão possível: você abre o Cursor e digita “crie para mim um app SaaS de gerenciamento de tarefas”. Quatro horas depois, você tem um caos em que nenhum arquivo compila. A seguir, um checklist de 12 passos que transforma a mesma ideia em um projeto pronto para ir ao ar em dois dias.

1. Defina uma única user story

Não uma funcionalidade, não um produto. Uma user story no formato “como X, quero Y para Z”. Exemplo: “como gerente de projeto, quero ver todas as tarefas da minha equipe em um único quadro para saber se vamos cumprir o prazo”. Só isso. Se você tem mais de uma story, ainda está cedo demais.

2. Escolha uma stack “chata”

Um primeiro projeto não é lugar para bibliotecas exóticas. Stack recomendada para quem está estreando no vibecoding: Next.js 15 + App Router, TypeScript, Tailwind, shadcn/ui, Drizzle + Postgres (Neon), tRPC, Vercel. Todos os modelos conhecem essa combinação, e existem milhares de exemplos públicos.

3. Crie um repositório e faça commit de um projeto vazio

npx create-next-app@latest, git init, push para o GitHub. Projeto vazio = ponto de referência zero. Toda mudança futura aparece como um diff a partir desse estado vazio.

4. Escreva o SPEC.md antes do primeiro prompt

Formato mínimo: um parágrafo com o quê, para quem, telas críticas, modelos de dados. No máximo 400 palavras. Especificar demais também é um erro: o agente perde espaço para sugerir coisas. Escreva a spec no padrão de qualidade esperado: é para esse estilo que o seu projeto vai convergir.

5. Escolha a IDE e o modelo

Para iniciantes: Cursor (a interface mais simples). Composer no Cursor, com o modelo Sonnet 4.6. Se você prefere o terminal, Claude Code. Fique com uma única ferramenta nos primeiros 30 dias e só depois compare.

6. Delegue tarefas “do tamanho de um café”

Cada prompt deve ser pequeno o bastante para que a implementação caiba em 15-20 minutos e o review, em 10. Se o Cursor fica digitando por 40 minutos seguidos, sua tarefa era grande demais: divida.

7. Faça commit a cada passo

Commits feios não têm problema. Depois de cada mudança verde: git add, um conventional commit curto e segue o jogo. Depois de uma hora de trabalho, você tem um histórico para o qual pode voltar com segurança. Sem commits, é garantido que daqui a quatro horas você não vai saber o que quebrou.

8. Mantenha separada uma lista de “depois”

Nos dois primeiros dias, não fique polindo estilos, não implemente a11y, não escreva testes para cada componente. Mantenha um TODO.md com a lista de dívidas e empurre a user story até ela funcionar. Otimizar antes de funcionar é receita para um burnout precoce.

9. Deploy primeiro em staging, depois em produção

Preview deploy da Vercel em cada PR: abra no navegador e veja se funciona de verdade. Localmente sempre funciona. Em staging, às vezes não. Em produção, vira problema do seu usuário.

10. Escolha uma métrica de sucesso

Algo que você consiga medir depois do lançamento. “Três colegas da minha equipe usam o quadro cinco vezes por semana” é uma boa métrica. “O app é bonito” não é.

11. Abra uma issue para cada ideia que você não vai fazer agora

Um issue tracker (o GitHub Issues basta) em vez de uma caixa de entrada na sua cabeça. Toda ideia, todo bug, todo “não seria legal se” vira uma issue com label. Cinco minutos agrupando tudo à noite e você enxerga como o dia seguinte deveria ser de verdade.

12. Marque uma retrospectiva depois de sete dias

Depois de uma semana, você senta, lê o git log, confere a métrica de sucesso, lê o TODO.md. Três perguntas: o que funciona? o que me atrasa? do que abrir mão? São trinta minutos que levam um projeto de “só um protótipo” a “um produto”.

Bônus: não construa um clone do Twitter

Um “clone do Twitter” como primeiro projeto parece fácil, porque o Twitter “tem funcionalidades simples”. Não tem. Tem autenticação, infinite scroll, tempo real, busca, ranking. Como primeiro projeto, construa algo que você mesmo vai usar na semana que vem. Um rastreador de hábitos, um bloco de notas com tags, um dashboard de finanças pessoais. Pequeno, seu, usado.

TL;DR

Um primeiro projeto de vibecoding dá certo quando você começa com uma spec, uma única user story e uma stack chata. Faça commit a cada passo, otimize no fim, meça o sucesso em usuários. Deixe o clone do Twitter para o quinto projeto.