Nivel: Medio
Casi todos empezamos un proyecto con la herramienta ya elegida, ya sea la que conocemos, la que vimos en un vídeo o la que usa todo el mundo.
Después la idea se va recortando hasta que cabe, y cuando por fin funciona ya no es lo que querías construir.
Hoy te dejo cuatro preguntas para responder antes de abrir ninguna herramienta y un prompt para que Claude Code proponga el stack a partir de tus respuestas.
Lo que veremos hoy:
Primero la idea, después el stack
Las cuatro preguntas previas
Cada respuesta decide una pieza
El prompt para elegir las herramientas
Qué descarto al elegir un stack
Tres preguntas para seguir el hilo con Claude
¡Apúntate al primer DIRECTO! APÚNTETE AQUÍ
Hola, soy Pol Marzà, AI Product Builder y cada semana escribo una nueva edición de Con Criterio, la newsletter sobre construir productos digitales con IA, con planificación, método y sin atajos. Si te han reenviado este email, puedes suscribirte aquí:
1. Primero la idea, después el stack
Llamamos stack al conjunto de herramientas con las que construyes un proyecto:
El framework (las piezas y reglas sobre las que se construye la web).
El sitio donde se guardan los datos.
El servicio donde se publica.
Lo habitual es empezar por una que ya conoces y preguntarte qué puedes hacer con ella.
El problema es que cada herramienta trae decisiones tomadas de antemano, y es tu idea la que se ajusta: o incorporas piezas que el proyecto no necesita, como una base de datos en una web que solo muestra información, o recortas una función que sí necesitabas porque tu herramienta no lo pone fácil.
El stack se decide después de saber qué construyes, no antes.
Por eso mi orden es siempre el mismo: primero escribo de qué va el proyecto, después dejo que esas respuestas decidan las piezas y, solo entonces, elijo herramientas concretas.
2. Las cuatro preguntas previas
Respóndelas por escrito, en una o dos frases cada una y sin mencionar ninguna herramienta:
Qué es: el proyecto en una frase, como se lo explicarías a alguien que no sabe de tecnología.
Quién lo usa y qué hace ahí: si solo lee o también escribe, publica o compra algo.
Qué información guarda y quién la cambia: si la actualizas tú de vez en cuando o la crean y modifican los usuarios.
Qué no hará la primera versión: las funcionalidades que dejas fuera (idealmente la primera versión solo debe resolver un problema).
La cuarta es la que más se salta y la que más stack te ahorra, porque cada función que dejas fuera es una pieza que no hay que elegir ni mantener.
Así quedan las respuestas para un portfolio:
Qué es: una web con mis proyectos y una forma de contactarme.
Quién lo usa: cualquiera que llegue desde un enlace. Solo lee y, como mucho, me escribe un correo desde un enlace a mi dirección.
Qué información guarda: la lista de proyectos, que actualizo yo cada pocas semanas. Los visitantes no guardan nada.
Qué no hará: cuentas de usuario, comentarios ni blog en la primera versión.
3. Cada respuesta decide una pieza
Si la información la cambias tú: puede vivir en archivos Markdown (texto con formato sencillo) dentro del propio proyecto, y no necesitas base de datos. Si la cambian los usuarios: necesitas una base de datos, que es donde la aplicación guarda y consulta información que cambia.
Si hay cuentas de usuario: necesitas autenticación, el sistema que gestiona el registro y el inicio de sesión, y eso arrastra una base de datos. Si no las hay: no instales ninguna de las dos cosas.
Si algo tiene que ocurrir fuera del navegador del usuario (enviar un correo, cobrar un pago, usar una clave que no debe verse): necesitas un backend, que es código que se ejecuta en un servidor y no en el navegador. Si no: basta una web estática, un conjunto de páginas ya construidas que se sirven tal cual.
Si hay pocas pantallas y sobre todo contenido: un framework pensado para contenido, como Astro, suele darte lo que necesitas. Si hay muchas pantallas que cambian según lo que hace el usuario: un framework de aplicaciones, como Next.js. Son dos ejemplos, y en cada categoría hay más opciones.
Estos son solo algunos ejemplos. No lo cojas como una receta para todo. En función del proyecto, las necesidades de stack serán unas u otras.
4. El prompt para elegir el stack
Abre Claude Code en una carpeta vacía, pega tus cuatro respuestas donde se indica y envía esto:
Voy a construir un proyecto web y quiero decidir el stack antes de escribir código. Estas son mis respuestas:
1. Qué es: [tu respuesta]
2. Quién lo usa y qué hace ahí: [tu respuesta]
3. Qué información guarda y quién la cambia: [tu respuesta]
4. Qué no hará la primera versión: [tu respuesta]
Explícamelo todo en lenguaje sencillo y define cada término técnico la primera vez que lo uses. Haz esto en orden y sin escribir código todavía:
1. Hazme, de una en una, las preguntas que falten para decidir el stack.
2. Propón el stack más pequeño que cubra mis respuestas. Para cada pieza, dime en una frase qué hace y cuál de mis respuestas la justifica.
3. Dime qué piezas habituales NO necesito y por qué.
4. Dime cuál de mis respuestas pesa más en la decisión y qué cambiaría en el stack si esa respuesta fuera distinta.
5. Guarda el resultado en un archivo STACK.md.El punto 3 hace el trabajo de filtro y el 4 te dice qué respuesta vigilar cuando el proyecto crezca. Si una respuesta cambia, por ejemplo porque decides añadir cuentas de usuario, vuelve a pasar el prompt con la respuesta actualizada y compara el resultado con tu STACK.md.
5. Qué descarto al elegir un stack
Descarto tres criterios que se usan mucho. El primero es elegir por popularidad, porque lo que usa todo el mundo resuelve los problemas de otros proyectos. El segundo es decidir leyendo comparativas de herramientas.
Una comparativa de herramientas te dice qué existe, no qué necesita tu proyecto.
El tercero es añadir base de datos y cuentas de usuario “por si acaso”, que es la forma más rápida de multiplicar lo que tienes que mantener sin que el proyecto gane nada hoy. Si más adelante hacen falta, se añaden entonces, con una necesidad concreta que te diga cómo.
6. Tres preguntas para seguir el hilo con Claude
Mi proyecto guarda reservas que crean los usuarios y que yo también quiero poder editar: ¿necesito una base de datos o me basta con un archivo dentro del repositorio, y en qué punto deja de ser suficiente?
Mi proyecto empezó como una web estática con Astro y ahora quiero añadir cuentas de usuario: ¿qué piezas tengo que añadir y qué parte de lo ya construido tendría que rehacer?
Mi stack consta de 5 piezas: ¿cómo compruebo cuál puedo quitar sin que el proyecto deje de funcionar?
7. Apúntate al primer DIRECTO!
Lo he dejado para el final, pero lo volveré a repetir la próxima semana (para los rezagados).
La semana pasada vimos cómo preparar tu ordenador para vibe codear (o para construir con IA, el título era un poco clickbait), hoy hemos hablado del stack, y la semana que viene te contaré la importancia de publicar tu web cuanto antes.
El directo es el paso que une todo eso: cómo empezar un proyecto para que la IA trabaje contigo y no a ciegas.
¿Qué veremos?
Te enseñaré a usar la plantilla con la que arranco todos mis proyectos. Es un punto de partida que obliga a la IA a entender qué vas a construir antes de escribir una sola línea de código. En resumen:
Si el proyecto aún no está definido, la IA te hace preguntas en lugar de ponerse a programar.
Todo lo que decides (producto, diseño, datos, roadmap) queda documentado, así que no tienes que volver a explicárselo en cada conversación.
Cada cambio importante deja rastro: qué se hizo y por qué.
Las ideas que surgen por el camino se guardan sin desviarte de lo que estás haciendo.
Antes de publicar, una revisión de seguridad busca claves expuestas y fallos comunes.
Funciona con Claude Code, Cursor y otros agentes, y con el stack que elijas.
El funcionamiento lo veremos en directo, paso a paso, y al final habrá tiempo para preguntas.
Domingo 1 de noviembre, 19:00 (Madrid, UTC+1). Online y gratuito.