Tu primer proyecto de vibecoding: checklist de 12 pasos antes de abrir Cursor

Tu primer proyecto de vibecoding empezará con la peor decisión posible: abres Cursor y escribes “hazme una app SaaS de gestión de tareas”. Cuatro horas después tienes un caos en el que ningún archivo compila. A continuación, una lista de verificación de 12 pasos que convierte esa misma idea en un proyecto listo para desplegar en dos días.

1. Define una sola historia de usuario

Ni una funcionalidad ni un producto. Una historia de usuario con el formato “como X quiero Y para Z”. Ejemplo: “como project manager quiero ver todas las tareas de mi equipo en un solo tablero para saber si llegaremos a tiempo a la fecha límite”. Y ya está. Si tienes más de una historia, todavía es demasiado pronto.

2. Elige un stack “aburrido”

Un primer proyecto no es lugar para bibliotecas exóticas. Stack recomendado para el vibecoder novato: Next.js 15 + App Router, TypeScript, Tailwind, shadcn/ui, Drizzle + Postgres (Neon), tRPC, Vercel. Todos los modelos conocen esta combinación y hay miles de ejemplos públicos.

3. Crea un repo y haz commit de un proyecto vacío

npx create-next-app@latest, git init, push a GitHub. Proyecto vacío = punto de referencia cero. Cada cambio futuro se verá como un diff respecto a ese estado vacío.

4. Escribe SPEC.md antes del primer prompt

Formato mínimo: un párrafo con qué, para quién, las pantallas críticas y los modelos de datos. Máximo 400 palabras. Especificar de más también es un error: el agente pierde margen para proponer cosas. Escribe la especificación con la calidad esperada, porque ese es el estilo hacia el que tenderá tu proyecto.

5. Elige el IDE y el modelo

Para principiantes: Cursor (la interfaz más sencilla). Composer en Cursor, modelo Sonnet 4.6. Si prefieres la terminal, Claude Code. Quédate con una sola herramienta durante los primeros 30 días y luego compara.

6. Encarga tareas “del tamaño de un café”

Cada prompt debe ser lo bastante pequeño como para que la implementación quepa en 15-20 minutos y la revisión en 10. Si Cursor se pasa 40 minutos seguidos escribiendo, tu tarea era demasiado grande: divídela.

7. Haz commit en cada paso

Los commits feos están bien. Después de cada cambio en verde: git add, un conventional commit corto y a seguir. Tras una hora de trabajo tienes un historial al que puedes volver con seguridad. Sin commits, dentro de cuatro horas tienes garantizado no saber qué se rompió.

8. Lleva aparte una lista de “para después”

Los dos primeros días, no pulas estilos, no implementes a11y, no escribas tests para cada componente. Mantén un TODO.md con la lista de deuda y empuja la historia de usuario hasta que funcione. Optimizar antes de que algo funcione es la receta para quemarte pronto.

9. Primero deploy en staging, luego en prod

Preview deploy de Vercel en cada PR: lo abres en el navegador y compruebas si funciona de verdad. En local siempre funciona. En staging, a veces no. En prod, ya es problema de tu usuario.

10. Elige una métrica de éxito

Algo que puedas medir después del lanzamiento. “Tres compañeros de mi equipo usan el tablero cinco veces por semana” es una buena métrica. “La app se ve bonita” no lo es.

11. Abre un issue por cada idea que no vas a hacer ahora

Un gestor de issues (GitHub Issues basta) en lugar de una bandeja de entrada en tu cabeza. Cada idea, cada bug, cada “¿no estaría genial si…?” acaba como un issue con su etiqueta. Cinco minutos de agrupar por la noche y ves cómo debería ser realmente el día de mañana.

12. Programa una retro a los siete días

Al cabo de una semana te sientas, lees el git log, revisas la métrica de éxito y lees el TODO.md. Tres preguntas: ¿qué funciona?, ¿qué me frena?, ¿qué dejo de lado? Treinta minutos que llevan un proyecto de “solo un prototipo” a “un producto”.

Extra: no construyas un clon de Twitter

Un “clon de Twitter” como primer proyecto parece fácil porque Twitter “tiene funcionalidades simples”. No es así. Tiene autenticación, scroll infinito, tiempo real, búsqueda, ranking. Como primer proyecto, construye algo que vayas a usar tú mismo la semana que viene. Un tracker de hábitos, una libreta con etiquetas, un dashboard de finanzas personales. Pequeño, tuyo y que de verdad uses.

TL;DR

Un primer proyecto de vibecoding sale bien cuando empiezas con una especificación, una sola historia de usuario y un stack aburrido. Haz commit en cada paso, optimiza al final y mide el éxito en usuarios. Deja el clon de Twitter para tu quinto proyecto.