Hoy te cuento qué hago entre crear el repositorio y escribir la primera línea de código, y por qué el despliegue es de lo último que me preocupa.

Lo que veremos hoy:

1. De la idea al repositorio

2. Crea el repositorio y clónalo

3. La primera conversación

4. El tamaño decide la documentación

5. Inicializar el proyecto

6. Requisitos, roadmap y fichas

7. Todo en local hasta que haya algo que enseñar

8. Qué descarto

9. Tres preguntas para seguir el hilo con Claude

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í:

Suscríbete ahora

Un pequeño recordatorio: El domingo hago un directo donde hablaré del proceso que sigo para construir cualquier proyecto. Mostraré el proceso de principio a fin en una sesión de 90 minutos. Puedes apuntarte gratis aquí.

1. De la idea al repositorio

En el envío anterior decidimos el stack con cuatro preguntas: qué es, quién lo usa y qué hace ahí, qué información guarda y quién la cambia, y quién hará la primera versión. Primero la idea, después el stack.

Hoy damos el siguiente paso: convertir esa idea en un repositorio donde el agente sabe qué construir antes de escribir nada. Para eso uso mi plantilla, project-template. Impone una regla sencilla: antes de tocar código, el agente lee la documentación del proyecto. Si está vacía, pregunta. Si está rellena, arranca con todo el contexto.

Un agente sin contexto no es más rápido. Solo se equivoca antes.

Un pequeño recordatorio: El domingo hago un directo donde hablaré del proceso que sigo para construir cualquier proyecto. Mostraré el proceso de principio a fin en una sesión de 90 minutos. Puedes apuntarte gratis aquí.

2. Crea el repositorio y clónalo

Esto lo haces tú, desde tu cuenta de GitHub:

• Abre github.com/polmarza/project-template y pulsa “Use this template” y después “Create a new repository”.

• Elige tu cuenta como propietaria, ponle un nombre y decide si será público o privado.

• Pulsa “Create repository”.

Ahora lo traes a tu ordenador. Crea una carpeta donde guardar tus proyectos (yo la llamo GitHub), haz clic derecho sobre ella, abre una terminal y escribe:

git clone [URL de tu repositorio]

Ya tienes una copia local del repositorio. De momento solo contiene la plantilla: documentos vacíos y las instrucciones para el agente.

3. La primera conversación

Abre Claude Code y selecciona la carpeta que acabas de clonar. Yo trabajo con la aplicación de escritorio, con el chat a un lado y la previsualización de la web al otro, pero funciona igual desde la terminal.

Escribe cualquier cosa para empezar. Un “hola” basta. La plantilla hace que Claude lea primero sus instrucciones, vea que la documentación está vacía y te conteste con una pregunta: qué quieres construir y para quién.

A partir de ahí le cuentas tu idea y él te hace preguntas. Aquí es donde reutilizas lo que decidiste en el envío anterior: qué es, quién lo usa, qué datos guarda y con qué stack lo vas a construir. Cuanto más claro llegues, menos preguntas habrá.

4. El tamaño decide la documentación

La plantilla trae ocho documentos, pero no todos los proyectos necesitan los ocho. Rellenar un modelo de datos para un portfolio es burocracia, y la burocracia inútil enseña a saltarse el proceso entero.

Por eso lo primero que hace Claude es clasificar tu proyecto en uno de tres tamaños:

• Sitio pequeño: landing, portfolio, web de contenido. Sin cuentas de usuario.

• Producto: hay usuarios, estado y datos que se guardan.

• Producto con negocio detrás: además hay que cobrar, medir o justificar decisiones.

En el portfolio del envío anterior, hecho con Astro y sin base de datos, Claude lo clasifica como sitio pequeño: PRD y arquitectura obligatorios, design system recomendado, y fuera negocio, roadmap, flujos de usuario y modelo de datos.

Los documentos que no aplican se borran, no se dejan vacíos. Un archivo vacío no se distingue de uno que se olvidó rellenar. Antes de borrar, Claude te enseña la lista y espera tu confirmación.

Después rellena los que quedan, uno a uno, confirmando contigo antes de pasar al siguiente. Cada paso queda guardado con un commit en tu ordenador.

5. Inicializar el proyecto

Con la documentación completa, Claude convierte la plantilla en tu proyecto. Reescribe el README para tu producto, rellena el archivo de instrucciones del agente con el nombre, el stack y las convenciones, ajusta la licencia y las variables de entorno, borra los restos de la plantilla y deja la primera entrada del registro de cambios.

El criterio es simple: cuando termina, ningún archivo habla de la plantilla. Todo habla de tu proyecto.

En este punto todavía no hay ni una línea de código. Solo hay acuerdos escritos.

6. Requisitos, roadmap y fichas

Cada funcionalidad del PRD lleva un identificador y un criterio para comprobar que funciona. Las priorizo con el método MoSCoW:

• Must: imprescindible para que el proyecto tenga sentido.

• Should: importante, pero puede esperar a la segunda vuelta.

• Could: deseable si hay tiempo.

• Won’t: descartado para esta versión, y se dice en voz alta.

En los proyectos de tamaño producto, el roadmap ordena esas funcionalidades: primero lo imprescindible, después lo demás.

Antes de construir cualquier funcionalidad, Claude escribe su ficha: qué se construye, qué requisitos cierra y cómo se comprobará cada uno. La revisa buscando ambigüedades y casos límite, y me deja a mí resolverlos. Yo leo la ficha, la corrijo si hace falta y la apruebo.

Solo entonces Claude empieza a construir.

La ficha es el contrato. Si no está aprobada, no hay código.

Cómo construyo a partir de ahí lo veremos en el directo.

7. Todo en local hasta que haya algo que enseñar

Desplegar es publicar el proyecto en una dirección de internet. Yo no lo hago el primer día. Mientras construyo, todo vive en mi ordenador: Claude arranca un servidor local y veo cada cambio en la previsualización al momento.

Si el proyecto tiene base de datos con Supabase, Claude levanta una copia local dentro de Docker. Así los errores de la base de datos aparecen en mi ordenador y no el día que subo a producción.

Para esto necesitas Docker instalado. Lo veremos en otro envío.

Despliego cuando hay algo que se puede mostrar: una landing, la primera pantalla funcional, lo que sea que alguien pueda abrir y entender. Ese momento lo veremos con calma en un próximo envío.

8. Qué descarto

• Pedir los ocho documentos siempre. El tamaño del proyecto decide cuáles. Si crece, se añaden los que faltan en ese momento.

• Construir sin ficha. Ahorra diez minutos hoy y cuesta horas de rehacer después.

• Desplegar antes de tener algo que enseñar. Una dirección pública con una página vacía no comprueba nada que no compruebe el servidor local.

• Conectar herramientas antes de tener stack. La plantilla no configura conectores hasta que la arquitectura está decidida.

9. Tres preguntas para seguir el hilo con Claude

• Mi proyecto empezó como sitio pequeño y ahora quiero añadir cuentas de usuario: ¿qué documentos me faltan y en qué orden los relleno sin rehacer lo que ya tengo?

• ¿Cómo escribo un criterio de aceptación comprobable para una funcionalidad de mi PRD? Dame un ejemplo con “dado, cuando, entonces” aplicado a mi proyecto.

• Quiero usar Supabase en local con Docker: ¿qué necesito instalar, cómo lo arranco y cómo paso después los cambios de la base de datos a producción?

  ---

¡Nada más por hoy! Pon esto en práctica y nos vemos en el directo del domingo :)

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:

1. Primero la idea, después el stack

2. Las cuatro preguntas previas

3. Cada respuesta decide una pieza

4. El prompt para elegir las herramientas

5. Qué descarto al elegir un stack

6. Tres preguntas para seguir el hilo con Claude

7. ¡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í:

Suscríbete ahora

1. Primero la idea, después el stack

Llamamos stack al conjunto de herramientas con las que construyes un proyecto:

1. El framework (las piezas y reglas sobre las que se construye la web).

2. El sitio donde se guardan los datos.

3. 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:

1. Qué es: el proyecto en una frase, como se lo explicarías a alguien que no sabe de tecnología.

2. Quién lo usa y qué hace ahí: si solo lee o también escribe, publica o compra algo.

3. Qué información guarda y quién la cambia: si la actualizas tú de vez en cuando o la crean y modifican los usuarios.

4. 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:

1. Qué es: una web con mis proyectos y una forma de contactarme.

2. 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.

3. Qué información guarda: la lista de proyectos, que actualizo yo cada pocas semanas. Los visitantes no guardan nada.

4. 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

1. 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?

2. 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?

3. 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!

APÚNTETE AQUÍ

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.

APÚNTETE AQUÍ

Muchas personas se bloquean al desplegar y publicar su proyecto, así que hoy voy a tratar de enseñarte las 6 herramientas que usa Claude (y yo) para trabajar en cualquier proyecto web. Si lo que quieres es construir apps para mobile o desktop, no te vayas porque también te interesa :)

Lo que veremos hoy:

1. El stack mínimo

2. Qué es Vercel y cómo funciona

3. Las tres cosas que tienes que hacer a mano

4. El prompt para que Claude Code instale lo demás

5. Qué descarto del stack mínimo

6. Tres preguntas para seguir el hilo con Claude

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í:

Suscríbete ahora

Antes de empezar me gustaría repetir la encuesta de la semana pasada en la que te pregunté sobre cuando prefieres asistir a un directo:

Igual es porque lancé la publicación en un puente (en España), pero la participación fue MUY baja ^^”

Bueno, ¡vamos al lío!

1. El stack mínimo

Las seis son Node.js, pnpm, Git, GitHub, Claude Code y Vercel. Las uso igual en una landing, en un portfolio o en una aplicación con usuarios, y lo que cambia de un proyecto a otro es todo lo demás (el framework, la base de datos, los servicios externos), que se decide cuando ya sabes qué quieres construir.

• Node.js es un programa que hace falta para que funcionen las herramientas con las que se construye una web, como Astro, que usaremos en el directo.

• pnpm descarga e instala las librerías, que son trozos de código hechos por otras personas y que tu proyecto reutiliza, y apunta cuáles son y en qué versión. Existen otros programas que hacen lo mismo (npm y yarn).

• Git guarda el historial de tu proyecto: cada versión que decides guardar (se llama commit) queda registrada y puedes volver a ella más adelante. También permite crear ramas, que son copias paralelas del proyecto para probar cambios sin tocar la versión principal, que se llama main.

• GitHub es un servicio en internet donde se guarda el proyecto con todo su historial. Esa carpeta del proyecto junto con su historial se llama repositorio.

• Claude Code escribe y modifica el código por ti a partir de lo que le pides en lenguaje normal. También puede ejecutar comandos en tu ordenador, y por defecto te pide permiso antes de hacerlo, así que en este envío le pediremos que instale el resto. Existe como aplicación de escritorio, en terminal, en editores y en la web, y yo uso la de escritorio porque permite ver los cambios a medida que los hace.

• Vercel publica tu proyecto en una dirección web a partir de lo que hay en GitHub.

Es bastante tralla para empezar, un buen glosario que te recomiendo que leas un par de veces antes de continuar.

No hace falta que te lo aprendas, pero es bueno que te vayan sonando estos conceptos porque irán saliendo más a menudo.

2. Qué es Vercel y cómo funciona

Vercel es el servicio que publica tu proyecto en una dirección web, por ejemplo tu-proyecto.vercel.app. Se conecta a tu repositorio de GitHub, lee lo que hay dentro y lo publica sin que tengas que subir archivos a mano.

Para entender cuándo publica, necesitas un concepto de Git: la rama. Un proyecto puede tener varias versiones en paralelo, y cada una de esas versiones es una rama. Parten del mismo proyecto y lo que cambias en una no afecta a las demás. Todo proyecto tiene una rama principal, que se llama main, y es la versión que consideras terminada.

Vercel actúa según en qué rama está el cambio:

main es el nombre de la rama principal de tu proyecto, y lo que hay en ella es lo que Vercel publica en la dirección principal.

Una previsualización es una copia de tu web con los cambios de esa rama, en una dirección que solo tienes tú. Sirve para abrirla, comprobar que todo se ve bien y decidir si el cambio se queda. Cuando lo das por bueno, lo incorporas a main y entonces pasa a ser público.

Así se trabaja después con Claude Code: le pides que haga los cambios en una rama, abres la previsualización que genera Vercel y, si te gusta, los incorporas a main.

3. Las tres cosas que tienes que hacer a mano

De las tres, la que puedes cambiar por otra es la primera. Yo uso Claude Code (I <3 Claude), pero si prefieres usar Codex, Gemini o cualquier otra opción, adelante:

1. Claude Code. Descarga la aplicación de escritorio desde este enlace. Luego inicia sesión (con Google) y abre la pestaña de Code.

2. GitHub. Crea una cuenta en https://github.com

3. Vercel. Regístrate en https://vercel.com eligiendo la opción de entrar con tu cuenta de GitHub (que has creado previamente).

El orden del punto 2 y 3 debe ser este ya que Vercel necesita estar vinculado con tu cuenta de GitHub para que, más tarde, puedas hacer los despliegues (poner tu web en internet) de manera automática.

4. El prompt para que Claude Code instale lo demás

En la pestaña Code, elige una carpeta nueva (por ejemplo, una llamada Proyectos) y pega este prompt:

Claude Code te pedirá permiso antes de cada comando, y conviene leer qué va a ejecutar antes de aprobarlo. Si algo falla, pega el mensaje de error en la misma conversación y pídele que lo resuelva.

Cuando el resumen final muestre las versiones de Node.js, pnpm y Git, el entorno está listo. Lo siguiente es decidir qué construir y qué más necesita, que es el tema del próximo envío.

5. Qué descarto del stack mínimo

Hay tres cosas que no forman parte del stack mínimo y que puedes dejar para cuando las necesites (o sientas curiosidad por ellas):

• Editor de código. La aplicación de escritorio de Claude Code muestra los cambios que hace en tus archivos, así que para empezar no necesitas abrirlos en otro programa.

• Base de datos. Una landing o un portfolio muestran lo mismo a todos los visitantes y no necesitan guardar datos. Cuándo añadirla y cuál elegir depende de la idea, y por eso es el tema del siguiente envío.

• Cuentas de usuario. Que la gente pueda registrarse exige una base de datos y un sistema de acceso, y nada de eso hace falta para publicar una primera web.

6. Tres preguntas para seguir el hilo con Claude

1. ¿Qué es ese gestor de paquetes, qué instala exactamente y cómo lo desinstalo si quiero?

2. Mi repositorio de GitHub es privado y mi cuenta de Vercel es Hobby: ¿qué restricciones tengo al desplegar y en qué casos me obliga a pasar a Pro?

3. ¿Qué diferencia hay entre un commit y una rama, y cuándo conviene pedirle a Claude Code que trabaje en una rama nueva en vez de en main?

A pesar de que respondieron menos personas de las que esperaba, ¡los resultados me han sorprendido!

En este post te cuento:

1. Quién eres, según las encuestas

2. Qué se está construyendo

3. Qué cambia en noviembre

4. Nuevo: buzón de sugerencias

5. Próximas publicaciones

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í:

Suscríbete ahora

1. Quién eres

Contestaron 28 personas, pocas, así que no es una radiografía de todos, sino de quien se animó a hablar.

El 57% me dijo que ya ha desplegado un proyecto. Solo el 11% no ha construido nada. El 62% trabaja con Claude Code. Yo había dado por hecho que escribía para gente que se atasca al empezar, y casi nadie está ahí: solo el 14% dijo no saber por dónde empezar.

Donde sí os atascáis es en dos sitios: desplegar y publicar (36%) y decidir qué herramientas usar (36%). Justo antes y justo después de construir.

Así que el problema no es de código, es un problema de criterio, y por eso existe esta newsletter :)

2. Lo que estáis construyendo

En los comentarios, alguien me contó que este mes creó su primera aplicación: un panel para entender cómo se comporta cada usuario de su membresía, con Vercel, GitHub y Supabase. Otra persona automatiza sus publicaciones en varias plataformas. Otra construye un sistema para que profesionales independientes validen una oferta. Nadie construye "una app": construye una herramienta para su propio problema. Yo escribo igual, y por eso funciona cuando coincidimos y falla cuando no.

También hubo un comentario que me quedo: alguien que no contestó la pregunta abierta porque su problema es el tiempo, con dos peques. Lo he tenido en cuenta para lo que viene.

3. Lo que cambia en noviembre

Octubre lo tengo ocupado con clases en directo para una escuela online, así que el cambio empieza en noviembre. Seguirá habiendo un envío semanal, el sábado, con la misma etiqueta de nivel, el índice y el criterio de siempre. Y el domingo habrá un directo semanal, grabado, para quien no pueda estar.

Cerca de un tercio de quienes leéis estáis en Latinoamérica, así que la hora importa. Domingo a las 17h de Madrid son las 10h en México y las 13h en Argentina. A las 19h son las 12h y las 15h. Voto abierto:

4. El buzón

Con tantos niveles distintos, la única forma que se me ocurre de escribir para ti es que me cuentes tu problema. Quiero que funcione como una sesión 1:1, solo que en público, para que les pueda ser de utilidad a otras personas.

Cuéntame qué quieres hacer y no sabes cómo, o qué herramienta no sabes si usar, en cuatro líneas.

Buzón de sugerencias

Cada semana elijo un problema, lo resuelvo en el envío del sábado y lo llevamos al directo del domingo. Y te contaré siempre qué he descartado y por qué.

Guárdate el enlace del buzón para cuando lo necesites :)

Igualmente, te lo añadiré en cada envío para que siempre lo tengas a mano.

5. Próximos envíos

Para no dejarte con las ganas (o sí), te avanzo lo que se viene en las próximas semanas:

Sábado 17/10 - Stack mínimo: Node, pnpm, Git, GitHub, CC, Vercel

Sábado 24/10 - Primero qué construyes, después el stack

Sábado 31/10 - Desplegar: de GitHub a Vercel

Domingo 01/11 - Primer directo: la web de principio a fin

Si tienes nivel básico, no te preocupes; explicaré todos los conceptos para que, tengas el nivel que tengas, lo puedas entender e integrar en tu base de conocimiento.

Recarga pilas que esto ya empieza.

¿Dudas?

Deja un comentario

En este post te cuento:

• Por qué construyo sin saber programar

• Por qué enseñar es más difícil que construir

• Por qué necesito saber quién eres

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í:

Suscríbete ahora

Construyo sin saber programar porque lo mío es conectar problemas con soluciones

Desde pequeño he sido una persona creativa y con mucha imaginación. Gané un concurso de dibujo y el colegio lo pintó en un trocito del muro del patio, gané un par de concursos literarios y antes de los 10 años ya emprendía: con mi hermana montamos una revista de pasatiempos que vendíamos a los vecinos.

Todo eso se paró en la secundaria y volvió con la fotografía. Intenté vivir de ella, pero me costaba poner precio a mi trabajo y acabé en ventas, y de ahí a roles de asesor, atención al cliente, marketing y diseño.

En todas las empresas se repitió lo mismo:

Soy la persona que ve problemas y plantea soluciones. Hasta finales de 2022, todas esas ideas se quedaban en una propuesta.

Siempre se me han dado mal los idiomas. Hablo y escribo perfectamente en castellano y catalán, pero el inglés se me ha resistido, y no me extraña no haber aprendido a programar a mano: lo he intentado y me aburre enormemente. Lo que se me da bien es cerrar los ojos y entender todas las piezas que necesita algo para funcionar, ver los flujos y cómo se conectan los datos.

A finales de 2022 llegó ChatGPT y, por primera vez, podía ejecutar mis propias ideas. La que siempre quise hacer es yoleo.io, un recomendador de libros.

En 2013 quedé primero con esa idea en el concurso de ideas emprendedoras de mi ciudad y no pasó de un diseño en Photoshop. Con la llegada de la IA la construí en HTML y CSS, de forma muy básica e insegura. Hoy está online, es accesible y tiene más de 200 usuarios.

Desde entonces he construido decenas de proyectos. Al principio eran muy sencillos, pero fui conociendo más opciones y formas de aplicar soluciones, y hoy construyo cosas que nunca pensé que sería capaz de hacer.

Construir es más accesible de lo que parece. Solo necesitas ganas de encontrar la solución, practicar y hacerte preguntas constantemente.

Enseñar es más difícil que construir porque cada persona llega con un nivel distinto

Enseñar es mucho más difícil que construir.

Este último año he compaginado mi trabajo de oficina con dar clases. Primero me invitaron a charlas online a raíz de lo que compartía sobre AI coding (nocodehackers fue de las primeras) y más tarde un par de escuelas me pidieron trabajar con ellas como profesor.

El problema se repite en las charlas, en las clases y también aquí, en Substack: quienes me ven tienen perfiles y niveles distintos. En clase, si doy una sesión básica los avanzados se aburren, y si doy una más técnica los demás se pierden. Allí al menos veo las caras y puedo corregir sobre la marcha, y en una newsletter no.

Por eso, desde hace poco, cada envío lleva una etiqueta de nivel debajo del título. Es un primer intento y todavía no sé si acierta.

Necesito saber quién eres para decidir qué descartar

Con esta newsletter mi misión es ofrecerte mi criterio y mi experiencia al construir con IA, pero ese criterio lo aplico según mis problemas actuales, que no tienen por qué coincidir con los tuyos. Sin saber quién eres, no puedo decidir qué merece tu tiempo y qué descarto. Son tres encuestas y una pregunta abierta.

Por último, ¿Qué estás construyendo o qué quieres construir?
Esta pregunta, al ser abierta, te agradecería que la respondieras en la sección de comentarios de este post. Con una línea me basta :)

Deja un comentario

Las respuestas me dirán cómo ajustar los próximos envíos. A partir de noviembre empiezo con directos y la newsletter va a cambiar para ser más práctica y dinámica. Te lo cuento en el próximo envío.

Seguro que en redes has leído más de una vez que para construir con IA no hace falta saber programar (aunque si sabes, tienes mucho ganado), pero lo que sí hace falta es poseer un set de habilidades.

Este set de habilidades serán las que determinen si terminas construyendo proyectos de forma exitosa o si te quedas por el camino.

Las 6 habilidades que veremos

1. Tolerancia a la ambigüedad

2. Descomposición de problemas

3. Criterio para evaluar el output

4. Persistencia frente al error

5. Comunicación precisa

6. Curiosidad técnica selectiva

Antes de empezar te quiero comentar que me han invitado a participar en el AI Summit que ha montado donde ha reunido a 20 expert@s en distintas disciplinas para que cuenten qué usan exactamente, qué han probado, qué no les funcionó y hacia donde va todo esto.

Algunas de las personas que hablaran seguro que las conoces:

· · · · · · · ·

Las charlas se publicaran del 21 al 25 de septiembre y la mía sale el viernes.

Pilla tu entra aquí.

1. Tolerancia a la ambigüedad

Vas a construir sin saber si funciona hasta que lo pruebas. La IA te entrega una solución que parece razonable, pero puede estar mal, y tenemos la costumbre de esperar a tener una certeza total antes de avanzar, así que es la primera que hay que soltar.

La tolerancia a la ambigüedad se entrena poniéndose límites de tiempo para decidir en vez de investigar hasta sentirse seguro. Por ejemplo: “pruebo esta librería 20 minutos, si no funciona cambio de enfoque.”

Construir bajo ese límite obliga a actuar sin la información completa que preferirías tener, y esa repetición es lo que entrena la tolerancia.

2. Descomposición de problemas

“Quiero una app de gestión de tareas” no es una instrucción ejecutable. “Quiero un formulario que guarde una tarea con título y fecha en una tabla” sí.

La habilidad de partir una idea grande en piezas pequeñas y concretas es lo que separa a quien construye rápido de quien se traba contra la IA en un bucle de prompts cada vez más vagos.

Esta habilidad se entrena escribiendo la tarea en pasos numerados antes de tocar la IA, en un papel o una nota:

1. Crear tabla de tareas.

2. Formulario con título y fecha.

3. Botón guardar que inserta en la tabla.

Si no puedes numerar los pasos, todavía no descompusiste lo suficiente, y ese bloqueo es el ejercicio en sí mismo.

3. Criterio para evaluar el output

Cualquiera puede pedirle algo a la IA.

La diferencia la hace saber si lo que devolvió es correcto, si tiene sentido o si es lo que realmente pediste. Sin esto, vas a acumular código que no se entiende y que falla de formas que no se pueden diagnosticar.

Antes de aceptar un output, conviene preguntarse por escrito qué se supone que hace y probarlo específicamente para eso, no de forma genérica.

Con el tiempo merece la pena llevar una lista personal de errores típicos que la IA repite (”siempre olvida las validaciones”, “asume que hay usuario logueado cuando no lo hay”) y revisarla antes de aceptar código nuevo.

TIP: Esta lista de errores también te puede servir para crear una SKILL para Claude, para que revise ese checklist antes de dar el producto por terminado.

4. Persistencia frente al error

Va a haber bugs, deploys rotos y momentos en los que la IA arregla una cosa y rompe otra.

La reacción de “esto no funciona, no sirvo para esto” mata más proyectos que la dificultad técnica real.

Cuando algo falla, conviene:

1. Leer lo que ha ocurrido (aunque no lo entiendas).

2. Pegar el error en una conversación y pedirle a la IA que te lo explique.

Llevar la cuenta mental de los bugs ya resueltos ayuda a contrarrestar la frustración cuando aparece el siguiente.

5. Comunicación precisa

Escribir prompts claros es una habilidad de comunicación, no una habilidad técnica.

Ser específico sobre qué se quiere, qué no se quiere y qué contexto importa determina la calidad de lo que se obtiene, igual que pasa al explicarle algo a otra persona.

Se entrena reescribiendo el prompt una vez antes de enviarlo y minimizar la ambigüedad, es decir, cambiar “hazlo más bonito” por “usa más espacio en blanco entre secciones y una tipografía más grande en los títulos”.

Practicarlo fuera de las herramientas de IA también sirve. Describirle una tarea a alguien sin que pueda preguntar nada de vuelta trabaja el mismo ejercicio de precisión.

6. Curiosidad técnica selectiva

No hace falta entender todo el stack, pero sí preguntar “¿por qué hiciste esto así?” o “¿cómo funciona esto?”.

Esta curiosidad es puntual, pero debe ser continua. Esta habilidad es la que, con el tiempo, te ayudará a construir tu modelo mental.

Es gratis y rápido: cuando la IA hace algo inesperado, preguntarle directamente antes de seguir, convierte cada sorpresa en una micro-lección en vez de dejarla pasar sin más.

Hay una séptima habilidad que no he mencionado: la paciencia.

Cada una de estas 6 habilidades se van construyendo con el tiempo, proyecto a proyecto. Si quieres construir bien a largo plazo, no hay atajos.

Preguntas para seguir el hilo con Claude

Si quieres seguir ahondando en este tema, te dejo algunas preguntas que le puedes soltar a Claude.

• Tengo un prompt que la IA malinterpreta siempre de la misma forma, ¿cómo reestructuro la instrucción para eliminar esa ambigüedad concreta?

• ¿Cómo distingo si un bug viene de un problema en mi lógica o de una limitación real de la herramienta que estoy usando?

• ¿Qué preguntas debería hacerle a la IA sobre una pieza de código que generó para verificar que entiendo lo que hace antes de aceptarla?

Es la publicación que mejor ha funcionado en la (corta) historia de mi newsletter:

• 373 visitas totales

• 11 likes

• 17 comentarios

• 3 restacks

• 7 veces compartido

Lo mejor de todo es que 13 personas se suscribieron a la newsletter y otras 16 personas se instalaron la extensión. Algunas que me lo han comentado son:

, , , , , y

La compartí porque me pareció la forma más sencilla de que cualquier persona, técnica o no, pudiera ver sus números sin liarse.

Si la probaste y te sirvió, me harías un favor enorme dejando una valoración en la ficha de la extensión. En serio, ayuda muchísimo más de lo que parece.

Dejar reseña

PERO (aquí viene el pero de siempre) llevo unos días dándole vueltas a algo.

Cuando compartí la extensión, varios de vosotros (makers, builders o gente que ya construye con Claude) me escribisteis básicamente lo mismo:

“Oye Pol, esto está genial, pero [rellena aquí tu petición]”

Lo genial de la extensión es que es un plug and play (enchufar y listo), pero los datos que trae son los que he decidido yo mostrar, cómo mostrarlos y lo peor es que son estáticos.

Así que, hoy te regalo la SKILL para que puedas meterle mano a tus datos de Substack :)

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í:

Suscríbete ahora

Vamos por partes

Esta SKILL es básicamente unos archivos e instrucciones que le enseñan a Claude donde tiene que buscar los datos reales de Substack (los datos que usa la plataforma en su propio panel) y dejártelos listos para consultar.

La SKILL te construye el mismo tipo de dashboard que la extensión.

A primera vista podrías pensar que la SKILL y la extensión para Substack de la semana pasada son lo mismo, pero realmente tiene mucho más.

Pero ojo: el dashboard es solo una posibilidad, no el objetivo. Lo que hace la SKILL de verdad es enseñarle a Claude dónde están tus datos y cómo leerlos. Que eso termine en un dashboard o simplemente en la respuesta a algo puntual que quieras saber, sin montar nada visual, depende de lo que tú le pidas.

He documentado un total de 120 endpoints distintos de la API de Substack. Los puedes encontrar todos aquí.

La gracia de mezclar la SKILL y esos endpoints es que puedes hablar con ellos, puedes preguntarle a Claude directamente, en lenguaje natural, cosas tipo “qué post terminaron más personas”, “cómo es la estructura de los posts que más retienen la atención”, etc.

Algunos de los endpoints que me han gustado más son:

• Finalización de lectura. No cuantas personas abren tu post, sino cuantas terminan de leerlo. La primera vez que lo veas duele un poco ^^”

• Solapamiento de audiencia. Qué otras newsletter comparten tus mismos lectores.

• Conversión por canal. A veces el canal que te trae más tráfico no es el que más suscriptores convierte.

• Comparativa contra posts similares. Si un poz concreto lo hizo mejor o peor que la media de los que se parecen.

Cómo instalar la SKILL

Para hacerlo de la manera más ordenada posible:

1. Crea una carpeta en tu ordenador llamada “substack stats” (por ejemplo)

2. Abre la carpeta dentro de Claude Code

3. Pégale la siguiente instrucción “Instala esta skill de forma global: https://github.com/polmarza/substack-stats-skill”

Cómo usar la SKILL

Una vez instalada pídele a Claude que te muestre tu dashboard.

El agente abrirá su navegador interno y navegará hasta Substack.

Al ser la primera vez, tendrás que iniciar sesión en tu cuenta en ese navegador (pones tu email, substack te manda un código, lo pones, listo).

Claude empezará a recopilar todos tus datos.

Esto suele tardar 1-2 min ya que lo he configurado para que las peticiones estén algo separadas en el tiempo, para no saturar el servidor de Substack.

También dependerá del número de publicaciones (newsletter y Notes) que hayas hecho a lo largo del tiempo.

Una vez termine, te mostrará algo así:

Guárdalo en “Descargas”. Este archivo .json es toda la data que ha podido recopilar Claude sobre tu(s) publicación(es) en Substack.

¿Recuerdas el panel que te he enseñado al principio del post? Pues ese es el que se poblará con los datos de este json descargado.

Substack guarda muchísimos más datos de los que al final te enseña y, por el momento, no tiene una herramienta nativa para interactuar con ellos.

Esta SKILL pretende subsanar eso.

Disfrútala :)

Ese era nuestro problema (porque creo que es compartido), hasta ahora.

Hoy te voy a enseñar el plugin “Panel para Substack” (que puedes instalar desde aquí) para que sientas la misma satisfacción que experimento yo cada día.

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í:

Suscríbete ahora

Qué descubrirás

Gracias a este dashboard no muestra (solamente) métricas vanidosas. Cuatro son las preguntas que vas a poder responder:

1. Qué temas funcionan y cuáles no

2. Qué notas merecen el rato que les dedicas

3. Si tu tasa de apertura se está torciendo y desde cuándo

4. (Si tienes más de una newsletter) cuál crece más, no cuál tiene más seguidores

AVISO: Verás que el dashboard está en inglés. Arriba a la derecha puedes cambiar el idioma de la interfaz clicando en el icono de la bola del mundo.

Cómo funciona

Solo tres pasos te separan de ver tus stats:

1. Instalas la extensión desde la Chrome Web Store

2. Una vez instalada pulsala y dale al botón “Sync all publications”.

Al sincronizar, el plugin abrirá una pestaña por cada publicación que tengas (si solo tienes una newsletter, solo abre una), lee tus estadísticas con la sesión que ya tienes puesta.

Si tienes muchos posts, tarda un par de minutos. Va despacio para respetar las consultas a la API de Substack.

BONUS: Ancla la extensión a tu barra de navegación para tenerla siempre a mano.

3. Cuando haya terminado, dale a “Open the dashboard” y verás algo así (adaptado a ti):

Esto de arriba es lo primero que verás cuando todo esté sincronizado: suscriptores, vistas, tasa de apertura, media de reacciones y altas atribuidas a posts. Debajo la progresión de suscriptores y de dónde vienen.

Puedes pulsar en cualquier post de la tabla para ver sus estadísticas sin tener que cambiar de pantalla:

Ahí ves de dónde vino su tráfico, qué enlaces se clicaron más, cómo fueron sus vistas día a día la primera semana. Además, en la columna de la derecha puedes comparar este post con tu propio post medio.

Si escribes en más de un sitio, la vista comparativa las pone todas juntas y te muestra el top 10 global de posts:

Si este post te resulta útil, ¿qué te parece si lo compartes? 😜

Compartir

Un comentario que lo cambio todo

Mientras estaba construyendo este plugin, leí un comentario de en una publicación de donde este segundo publicaba sus stats (lo hace cada martes, al desnudo).

Mike comentó:

¡Y no puede tener más razón!

Un post que mandas a 1.800 personas le va a ganar siempre a uno que mandaste a 200, aunque el viejo llegara a una porción mucho mayor de personas.

Para eso el panel tiene dos modos:

En “absoluto” ves las cifras tal cual, como en cualquier dashboard. Pero en relativo el alcance se divide entre los que de verdad recibieron cada envío y la interacción entre las vistas de ese mismo post.

Te lo muestro con un par de capturas:

Absolutas

Relativas

Los datos son los mismos en ambas, pero cambia contra qué lo mides. A mi me cambió el orden de cuáles creía que eran mis mejores posts.

¿Y los datos?

Tus datos son tuyos y yo no los quiero para nada, así que todo se guarda en tu ordenador.

No hay servidor, ni cuenta, registro o analítica. La extensión habla con Substack para obtener los datos y estos van directos a tu navegador. Las estadísticas se guardan en el almacenamiento que Chrome reserva en tu propio equipo.

AVISO: Si cambias de ordenador tendrás que volver a sincronizar tus datos (un par de minutos)

Un par de cosas más antes de terminar, porque prefiero ser transparente:

1. El plugin usa la misma API interna de Substack, pero no está documentada (ni es oficial), así que si Substack la cambia, tocará actualizar (yo me encargo).

2. Como he comentado antes, la interfaz está en inglés (por si esto peta y llega lejos). Arriba a la derecha tienes un botón (globo) para pasarla a español.

Agradecimientos

Antes de terminar me gustaría dar las gracias a 3 personas:

• A porque fue el primero que vi que compartía sus stats. Él lo hace a través de un Artefacto de Claude (amo a Claude) y espero que ahora lo haga a través de mi extensión.

• A por encenderme la chispa de lo que comparto hoy. Su primera solución fue descargarse el CSV (aunque él mismo declaro que era un rollo) y hoy ha publicado su propio plugin.

• A por inconformista. Porque, charlando, me dijo que le molaría un panel donde no solo ver las estadísticas vanidosas, sino las relativas. Porque no es lo mismo ver tus stats cuando tenías 10 seguidores que cuando tengas 10k.

¿Te ha resultado útil este recurso?

Todos los recursos y materiales de Con Criterio son gratuitos, pero si me quieres apoyar para que siga construyendo y compartiendo de esta manera, puedes invitarme a un café :)

Invítame a un café

¡Hola, hola!

Antes de empezar a leer fíjate que he grabado una nota de voz. Quería probar esta nueva funcionalidad de Substack y como siempre me han dicho que tengo voz de locutor… Pues vamos a darle uso. Así que te invito a escucharme :)

¿Qué tal el verano?

Ya, seguro que pensaste que no me volverías a ver por aquí…

El pre-verano estuvo lleno de cambios, mucho trabajo y nuevas responsabilidades y abandoné un poco esta newsletter porque, ya sabes, escribo por placer y por compartir, pero esto no es mi negocio.

Así que estoy feliz de retomar esto con ganas de aportar nuevos conceptos, con criterio :D

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í:

Suscríbete ahora

Hoy quiero hablarte del orden en el cual construyo mis proyectos. El orden es importante para que tengas una estructura que puedas replicar, para que cada proyecto tenga un orden.

Habitualmente construyo de dentro hacia afuera, es decir:

1. BBDD

2. Backend

3. Frontend

Esto tiene sentido la mayoría de las veces, sobretodo cuando ya tengo claro lo que quiero construir.

Por qué funciona

Funciona porque la base de datos es el “contrato” de verdad de la aplicación. Ella define:

• Qué entidades existen

• Cómo se relacionan

• Qué es obligatorio

• Qué es único

Si cambias el modelo de datos después de construir el frontend, arrastras cambios en cascada: formularios, validaciones, tipos, consultas… todo se reescribe.

El backend expone ese modelo mediante reglas de negocio y permisos, así que hay que construirlo después de la BBDD, pero antes del front para evitar diseñar pantallas alrededor de una API que aún no sabes cómo se comportará (paginación, errores y/o estados intermedios).

El frontend es la capa más barata de rehacer. Cambiar un componente cuesta minutos, pero cambiar un esquema de datos con datos reales ya insertados cuesta horas o migraciones (y cosas que se pueden romper).

Cuándo NO aplica

Si estás validando una idea de producto y no sabes si el usuario la quiere, construir la BBDD primero es prematuro. Ahí conviene “frontend-first” con datos mockeados para iterar sobre UX y descartar rápido (lo que vendría siendo vibe coding).

Con herramientas como Lovable, el coste es mejor y reduce parcialmente la penalización de invertir el orden.

Perfecto, ya tenemos claro cuando aplicar una u otra metodología. Ahora bien, ¿cómo empezar?

Cuando empiezas frontend-first (Lovable u otra herramienta similar)

Realmente no necesitas una documentación formal; necesitas responder tres preguntas básicas antes de escribir el primer prompt:

1. Qué pantalla o flujo concreto vas a enseñar (no “una app de gestión de tareas”, sino “el flujo de crear una tarea y marcarla como hecha”).

2. A quién se lo vas a enseñar y qué decisión tomará esa persona al verlo (invertir, usarlo, darte feedback).

3. Qué datos son reales y cuáles son inventados para la demo (esto evita que luego confundas mock con producción).

Con esto en mente ya puedes entrar a Lovable.

Cuando empiezas dentro-fuera (BBDD → backend → frontend)

Mientras que en la opción anterior podías improvisar más (y de hecho, esa es su gracia), aquí sí conviene un protocolo, porque el coste de un agente escribiendo código sin entender el dominio completo, es alto.

Cuando construyo así, siempre uso mi plantilla project-template

Lo que resuelve o con lo que te ayuda esta plantilla en este contexto es:

• Antes de que el agente empiece a escribir código, lee la carpeta docs/. Los documentos por defecto están vacíos, así que primero te empieza a hacer preguntas para rellenarlos.

• Cada funcionalidad (feature) se acuerda primero en una ficha (docs/features/) con criterios de aceptación comprobables antes de implementar nada.

• Un script en CI verifica que ningún requisito quede sin su test o justificación de porqué no aplica.

• El registro en changelog/ deja trazabilidad de qué se construyó y por qué, evitando así que en la siguiente sesión el agente repita contexto o se pierda.

La diferencia práctica entre ambos casos es que en Lovable clarificas en tu cabeza porque vas a iterar rápido y descartar (vibe coding), mientras que en el otro caso clarificas en documentos porque el coste de deshacer un error de modelo de datos es demasiado alto como para ir improvisando (se acerca más a SDD o Spec Driven Development).

¡Nada más por hoy! Espero que la lectura te haya resultado interesante :)

Ahora lo más importante es que empieces a aplicarlo. No te quedes solo con la teoría y el “ah, ya lo entiendo”. Hasta que no lo pruebes no verás si realmente te sirve para ti.

¡Hasta la semana que viene!

¿Te ha resultado útil este recurso?

Todos los recursos y materiales de Con Criterio son gratuitos, pero si me quieres apoyar para que siga construyendo y compartiendo de esta manera, puedes invitarme a un café :)

Invítame a un café

Y es normal, ya que la mayoría de creadores de contenido, cuando hablan de vibe coding hablan de hacer páginas web.

Pero ya tu sabes que yo no soy la mayoría.

Hoy vamos a hablar de cómo, cuándo y por qué construir una app en mobile. ¿Por qué piensas que me decidí por este formato? Vamos a verlo 😜

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í:

Suscríbete ahora

Antes de entrar al tema quiero explicarte qué he desarrollado exactamente: se trata de un juego de rol y exploración urbana. El mapa del mundo (si, porque puedes jugarlo desde cualquier rincón del planeta) aparece cubierto de niebla y se revela a medida que caminas por la ciudad, en la vida real.

Pero no se queda en el mapa. El mundo esta poblado de lugares con narrativa propia: tabernas, academias, bosques, torres… En cada lugar puedes interactuar con un DM (un director de juego, en este caso una IA) que te narra una historia y responde a tus decisiones.

A partir de ahí puedes construir equipamiento (espadas, escudos, cascos…) para enfrentarte a maleantes que aparecen en tu camino mientras exploras el reino.

La decisión que definió el proyecto desde el inicio fue la necesidad de tener el GPS activo aunque el móvil esté bloqueado en el bolsillo. Eso es lo que hace que puedas ir caminando tranquilamente sin tener el móvil en la mano y que este vibre cuando te cruzas con un malhechor.

Otra característica técnica que me hizo decidirme por una aplicación nativa fue la necesidad de persistencia (de datos) garantizada. En el caso de una PWA (Progressive Web App), el sistema operativo Android o (sobretodo) iOS pueden borrar datos de las aplicaciones si consumen mucho o hace tiempo que no se usan.

Ahora sí, al lío.

Como todo desarrollo, este consistió en tres fases:

Clarificación → Construcción → Distribución

Clarificación

En esta primera fase no hay diferencia respecto a clarificar el desarrollo de un sitio web; el PRD es el mismo ejercicio, es decir, definir para quién es la aplicación, qué hace y qué decide no hacer.

La arquitectura, el modelo de datos, el flujo de usuario, la monetización… Aunque sean plataformas distintas, todas tienen el mismo esqueleto.

Recuerda que en la clarificación también piensas en el stack, y aquí es donde viene el gran cambio, ya que al ser una app nativa no puedes desarrollar con React, Astro o Vue si no que tienes que hacerlo con Flutter o Swift (entre otras).

PRO TIP: Es muy importante que antes de decidir en que builder quieres construir (Lovable, Bolt, Cursor…) definas qué stack necesitas, ya que eso te va a condicionar todo lo demás.

Construcción

En mi caso me decidí por Flutter ya que te permite escribir el código una vez y compilarlo para iOS y Android.

Con Claude Code como agente, la construcción sigue la misma lógica que cualquier otro proyecto vibe codeado:

1. Te apoyas en un agente para redactar las specs (clarificación)

2. Adjuntas dichas specs al proyecto (Local o en la nube)

3. Empieza de dentro hacia fuera (datos → backend → frontend)

4. Revisas

5. Iteras

La diferencia con una web no está en el método de trabajo con la IA, es una diferencia de herramienta, no de filosofía.

Distribución

El gran cambio, para mí, llegó aquí.

Una web se despliega en Vercel y en segundos la tienes viva y accesible por URL, actualizable al momento. Una app móvil, no.

Una app pasa por tiendas de aplicaciones, revisión de Apple y de Google, procesos de testers (antes de llegar a producción); tiempos con los que no contabas. Sin menospreciar el pago de las licencias de desarrollador 😅 (99€/año en el caso de Apple y 25€ para Android).

Actualmente me encuentro en esta fase, la de testeo. Para que la aplicación salga adelante y cualquier persona se la pueda descargar, necesito que varios usuarios la estén probando, rompiendo y dándome feedback.

Así que si has llegado hasta aquí, ¿te animas a jugar?

Jugar a Wanderlore

Hoy vengo a hablarte sobre las 3 preguntas/respuestas que te ahorrarán muchísimo tiempo cuando construyes con IA.

Ya te adelanto que hoy vas a ver muchos treses 😂

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í:

Suscríbete ahora

Vivimos en la era de la inmediatez, lo queremos todo para ayer y el problema es que muchas veces aplicamos esta filosofía cuando nos sentamos delante del ordenador y nos ponemos a construir nuestro próximo proyecto.

Es posible que este método (el vibe coding puro y duro) funcione durante las primeras horas o para proyectos pequeños, pero cuando quieres empezar a construir algo con cierta seriedad, el no haber planificado nada de antemano te va a salir muy caro.

Yo aprendí esto a la fuerza.

Hace 3 años construía sin criterio. Pensaba: “¿para qué voy a perder tiempo en redactar lo que quiero construir si lo tengo todo en la cabeza?”

¡Me sentía invencible!

• Invencible hasta que las cosas empezaban a no cuadrar.

• Cuando me empezaba a contradecir.

• A no recordar las decisiones.

Entonces un buen amigo me recomendó que “cómo mínimo tienes que responder a estas 3 preguntas”:

1. QUÉ quieres construir

2. Para QUIÉN

3. POR QUÉ

La tercera pregunta responde a la pregunta de por qué debe existir tu app, qué problema resuelve concretamente. Es quizá la pregunta más importante de las tres, ya que si solo te sirve a ti, esta bien construirla, pero si quieres que tu app tenga éxito, debe resolver un problema real.

La respuesta a estas 3 preguntas es la especificación mínima que debes redactar antes de empezar a construir nada.

Y no, no es perder el tiempo, es lo que va a evitar que construyas al tuntún y que acabes pariendo un Frankenstein.

Con esto ya puedes empezar a construir con Lovable, pero si lo tuyo es Claude Code, te recomiendo que uses esta plantilla que creé hace algún tiempo:

Project Template

Entre otras cosas, dentro encontrarás:

CLAUDE.md

Archivo de referencia que lee cualquier agente de codificación antes de tocar el proyecto. Si docs/ está vacío, obliga al agente a preguntar "qué quieres construir y para quién" y a rellenar la documentación en orden antes de escribir código. Define stack tecnológico, convenciones, qué NO hacer, y protocolo obligatorio de cambios: changelog, actualización de docs, revisión de seguridad.

docs/

Carpeta de documentación estructurada: prd.md, business.md, design-system.md, architecture.md, data-model.md, roadmap.md, user-flows.md. Es donde viven las respuestas a qué, quién y por qué, convertidas en especificación real.

changelog/

Registro de cada cambio relevante: fecha, tipo (feature, fix, refactor, migración, documentación, configuración), qué se hizo, qué se modificó, por qué.

mejoras/

Backlog de ideas que no entran en el sprint actual: título, descripción, motivación, prioridad.

No es perfecto y seguro que se puede mejorar, pero es un punto de partida mucho mejor que empezar a promptear sin criterio.

¿Cuál es tu método? Te leo en los comentarios 🤓

Así que me planté delante de una bifurcación.

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í:

Suscríbete ahora

Local con el Mac despierto, o la nube

La primera opción era quedarme en local y obligar al Mac a no dormirse: evitar el reposo, programar un despertador, mantener la sesión viva. Funcionaría… mientras el Mac estuviera encendido, enchufado y de buen humor. Frágil.

La segunda era sacarlo todo de mi máquina y meterlo en la nube. Más trabajo de montaje, pero a cambio: corre aunque el Mac esté apagado, sin permisos de macOS de por medio, sin servidores que mantener. Elegí la nube. Si el objetivo era “olvídate y que funcione”, no había color.

Pero la nube traía una pregunta que tuve que decidir con criterio: mi agente guardaba su memoria —los posts, las métricas, lo aprendido— en una base de datos local. Una tarea en la nube no puede leer un archivo de mi disco. ¿Dónde vivía entonces la memoria?

La respuesta resultó casi indolora: Cloudflare D1, que es literalmente SQLite en la nube. Migré la base sin apenas tocar el código. La memoria dejó de ser un archivo en mi disco para ser algo que el sistema alcanza desde cualquier sitio.

La decisión de la que más orgulloso estoy

Aquí viene la parte con criterio de verdad. Cuando moví la lógica a la nube, tenía dos caminos:

1. Dejar que la IA, además de escribir los posts, razonara también los números: qué ángulo funcionó mejor, qué puntuación tenía cada uno.

2. Que la IA solo escribiera, y que el cálculo lo hiciera código determinista.

Elegí el segundo, y creo que es la decisión clave de todo el proyecto. Porque esto es un experimento: el sentido es medir qué funciona y aprender con el tiempo. Y en un experimento, el instrumento de medida tiene que ser constante. Si le pides a un modelo de lenguaje que puntúe, con los mismos datos puede darte resultados ligeramente distintos un día u otro — y peor aún, ese ruido se realimenta, porque la puntuación de hoy condiciona el contenido de mañana. Una regla que cambia de longitud cada vez no sirve para medir nada.

La frase que me quedó grabada: la IA escribe, el código calcula. Para lo que es juicio —redactar, elegir el ángulo— la IA. Para lo que es un cálculo fijo —puntuar, rankear— código. Mezclarlos te da lo peor de los dos mundos.

Lo que aprendes solo cuando lo enchufas

Sobre el papel todo encaja; al conectarlo aparecen las sorpresas. Tres que me llevo:

Pagar calderilla a propósito. En local, la IA escribía los posts con mi suscripción de Claude, gratis. Pero una tarea en la nube no puede usar mi suscripción. Para que el sistema fuera de verdad autónomo, el agente llama directamente a la API de pago. Cuesta unos céntimos al mes — y los pago encantado a cambio de independencia total. A veces la decisión correcta es dejar de optimizar el “gratis”.

Los detalles de integración que ningún tutorial cuenta. El conector “oficial” de Buffer hablaba con un servidor interno; mi token personal iba contra otra dirección distinta. Media hora de errores 401 hasta dar con ello. La fiabilidad de una automatización casi nunca está en la idea, está en estos detalles.

La IA no sabe contar. Bluesky limita los posts a 300 caracteres, pero el modelo se pasaba una y otra vez por mucho que se lo pidiera. La solución no fue rogar más fuerte, sino poner una red: si un post se pasa, el sistema le pide que lo reescriba más corto, hasta que cabe.

El último ajuste: que sonara a persona

Cuando por fin publicaba, los textos salían correctos pero telegráficos: frase corta, punto, frase corta, punto. Sonaban a lista, no a alguien contando algo. Curiosamente, la culpa era mía: para respetar el límite de caracteres le había pedido al modelo “frases secas”, y eso producía justo ese estilo a trompicones. Cambié las instrucciones hacia una prosa más narrativa y humana, y el cambio se nota.

[VISUAL 4: antes/después del tono — telegráfico vs narrativo, mismo contenido]

Qué me llevo

El agente quedó funcionando: cada mañana, en la nube y sin mi Mac de por medio, recogía métricas, escribía y publicaba, y guardaba lo aprendido. Y aunque ahora paro este experimento para llevar la idea a LinkedIn, me llevo tres cosas en la mochila:

• Entiende la herramienta antes de forzarla. Medio drama me lo ahorraba sabiendo qué era /loop.

• La IA para el juicio, el código para los números. No los mezcles.

• La fiabilidad vive en los detalles, no en la idea. Lo difícil no es construir el agente; es que corra solo cuando no estás mirando.

Que, mira, es exactamente la tesis con la que empecé: el problema no es construir, es la distribución. Solo que esta vez el experimento me lo demostró a mí mismo.

Fin de la serie.

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í:

Suscríbete ahora

El plan era sencillo. Cada mañana, el agente escribiría tres versiones de un post (tres ángulos distintos), las publicaría en Bluesky a través de Buffer, recogería las métricas del día anterior y ajustaría el contenido del siguiente. Y lo más bonito: el contenido iría sobre cómo se estaba construyendo el propio agente. El medio como mensaje.

Para el disparo diario tiré de lo que tenía más a mano: /loop, el comando de Claude Code que repite una tarea cada cierto tiempo. “Que se lance solo a las ocho”, pensé. Dejaba el Mac en reposo por la noche y, en teoría, a la mañana siguiente el agente habría publicado.

Spoiler: no funcionó 🥲

El muro

Lo primero que descubrí es que /loop no estaba pensado para esto.

/loop vive dentro de una sesión abierta y necesita el ordenador despierto: cuando el Mac entra en reposo, macOS suspende los procesos y el temporizador, sencillamente, no dispara.

Pero el problema de verdad llegó cuando intenté forzarlo.

Para que el agente publicara sin pedirme permiso cada mañana, edité a mano la configuración de permisos. Y ahí Claude Code empezó a bloquearse: cada vez que enviaba un mensaje, ocurría esto: process exited with code 1 — an internal error occurred (EPERM). Treinta minutos sin poder trabajar, desinstalando y reinstalando para recuperar el control.

EPERM significa “operation not permitted”. Es un error del sistema de archivos, no de la configuración de Claude. ¿La causa de fondo? Tenía todo (el proyecto y la carpeta de configuración de Claude) en un disco externo. Las escrituras y los bloqueos que Claude hace constantemente empezaron a chocar con los permisos del volumen externo.

La lección que me llevé

Pasé un buen rato culpando a mi configuración. Estaba equivocado: un EPERM casi nunca es culpa de tu config, sino del sistema de archivos que tienes debajo. Pero la lección más útil no fue esa, fue otra:

Había confundido dos cosas que parecen iguales y no lo son: lo atendido y lo desatendido.

/loop es una herramienta atendida: brilla cuando estás delante, con la máquina despierta y la sesión viva. Para vigilar un deploy mientras trabajas, para iterar sobre una tarea hasta terminarla, es perfecta. Lo que yo necesitaba era lo contrario: algo desatendido, que corriera cada mañana durante semanas, con el Mac apagado y sin nadie delante. Dos mundos distintos.

Y ahí estaba el verdadero problema de diseño: no era de permisos, era de arquitectura. Mi automatización dependía de mi portátil, y un portátil se duerme, se apaga y vive en un disco que se queja. Si quería que aquello corriera de verdad solo, tenía que sacarlo de mi máquina.

En la segunda parte cuento cómo lo hice: moverlo todo a la nube, qué decisiones tomé con criterio por el camino (incluida una que me hizo pasar de “gratis” a pagar unos céntimos al mes, a propósito), y cómo quedó un sistema que, literalmente, se cuenta a sí mismo.

Hoy vengo a hablarte de una elegante solución para resolver un problema común.

Cada vez que monto un proyecto aparece la misma situación: necesito un correo profesional con mi dominio, estilo “hola@tuproyecto.com”

La solución que aplicaba hasta hace unos meses era contratar un plan de email de Hostinger (porque el 99% de los dominios los registro desde ahí).

El tema es que hacerlo de esta manera comporta pagar unos 4 euros al mes por buzón (que casi no vas a usar).

Así que hoy te quiero plantear la alternativa que estoy usando desde principios de año.

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í:

Suscríbete ahora

Cloudflare + Gmail

Cloudflare tiene un servicio gratuito llamado Email Routing. La idea es simple: en lugar de contratar un buzón de correo para cada proyecto, creas un alias.

Un alias es una dirección como hola@tuproyecto.com que no tiene buzón propio. Cuando alguien te escribe ahí, el mensaje llega directamente a tu Gmail.

La diferencia con Hostinger u otros hostings de email es que ellos te alojan un buzón real en sus servidores. Cloudflare no aloja nada, solo reenvía. Para el 95% de proyectos es más que suficiente, y el coste es cero.

Puedes crear tantos alias como quieras y repetirlo con todos los dominios que tengas. Todo llega al mismo Gmail (o a la dirección que desees).

El paso que mucha gente se salta es el del envío. Es decir, puedes configurar Gmail para que al responder, el correo salga con la dirección de tu dominio. El destinatario ve hola@tuproyecto.com, no tu cuenta personal. Recibir y enviar, sin pagar nada.

Cómo se configura

Parte 1: Recibir correo

1. Entra a tu dominio en Cloudflare y ve a Compute > Email Service > Email Routing

2. Haz clic en “Onboard Domain” y selecciona tu dominio. Cloudflare añade los registros necesarios automáticamente

3. Ve a Destination Addresses, añade tu Gmail y confírma el email de verificación que te mandan

4. Ve a Routing Rules > Create routing rule, escribe el alias que quieres (hola, contacto, soporte...) y selecciona tu Gmail como destino

Parte 2: Enviar desde Gmail con tu alias

5. En Gmail ve a Ajustes > Cuentas e importación > Enviar correo como > Añadir otra dirección

6. Escribe el nombre y la dirección del alias. Desmarca “Tratarlo como un alias”

7. Servidor SMTP: smtp.gmail.com, puerto 587. Usa tu cuenta Gmail con una contraseña de aplicación (necesitas el 2FA activado en Google)

8. Verifica con el código que llega al Gmail

9. Al redactar un correo ya puedes elegir desde qué dirección envías

Nota importante para usuarios de España

En España, durante los días de partido de LaLiga, las operadoras bloquean rangos de IPs de Cloudflare para cortar retransmisiones ilegales. Tu web puede quedar inaccesible como daño colateral, sin que hayas hecho nada mal.

Si usas Cloudflare solo para Email Routing esto no te afecta. Pero si también tienes la web con el proxy activo, conviene saberlo: en el panel de DNS verás un icono de nube junto a cada registro. Si está naranja, el tráfico pasa por Cloudflare. Si está gris, va directo a tu servidor. Durante los días de partido puedes ponerla en gris para evitar el bloqueo.

¡Nada más por hoy! Guía cortita, al pie, como a mi me gustan :)

Si tienes alguna duda puedes dejar un comentario y estaré encantado de ayudarte. Y si te ha gustado la publicación, no olvides compartirla.

Compartir Con Criterio

Si me has estado siguiendo, sabrás que cuando empecé a construir con IA, lo hice con ChatGPT. Mi segundo gran salto fue Lovable, una herramienta que me permitió tener un producto funcionando en horas, sin saber prácticamente nada de código.

Pero con el tiempo aparecen los roces.

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í:

Suscríbete ahora

Con Lovable, la documentación que te permite adjuntar la herramienta es limitada. Puedes añadir una pequeña base de conocimiento, pero no una documentación viva que el agente consulte y actualice de forma dinámica. Además:

• Solo puedes construir con React y Vite, lo que cierra la puerta a otros stacks.

• Cada conversación queda dentro del chat, sin una forma sencilla de convertirla en conocimiento reutilizable.

• La personalización del agente tiene un techo bajo.

• Las integraciones disponibles son las que son: no puedes conectar MCPs propios ni usar Skills.

No es una crítica a Lovable. Para empezar, es fantástico. Pero llega un momento en que necesitas más.

Claude Code Desktop: dos modos de trabajo

La app de Claude tiene una pestaña llamada Code.

Cuando se habla de Claude Code en LinkedIn, casi todo el mundo lo asocia a la terminal: comandos, CLI y con perfiles técnicos.

Y es comprensible, porque así es como se presentó al principio. Pero existe otra forma de usarlo que muy poca gente menciona: la versión de escritorio. Con grandes funcionalidades, una interfaz visual, y que yo, personalmente, nunca he abandonado. Todo lo que he construido con Claude Code lo he hecho desde ahí.

Confesión: Con Claude, nunca he tocado el terminal.

Desde la versión de escritorio puedes trabajar de dos formas distintas:

a. Modo remoto (con GitHub)

Seleccionas un repositorio de GitHub y una rama.

Claude crea un entorno temporal en la nube donde trabaja con ese código. Haces tus peticiones en lenguaje natural, él implementa los cambios, y cuando estás conforme le pides que lo suba a GitHub. Limpio, trazable y sin salir del chat.

b. Modo local

En lugar de un repositorio remoto, apuntas a una carpeta de tu máquina. Aquí es donde aparece algo que te resultará muy familiar si vienes de Lovable: el preview en tiempo real.

Mientras Claude va haciendo cambios, los ves reflejados al instante. Y cuando quieres subir el proyecto a GitHub, simplemente se lo pides. A través del MCP de GitHub, Claude crea el repositorio, sube el contenido y gestiona los cambios. Sin terminal.

Una experiencia muy similar a la que ya has experimentado con Lovable, pero con todo el potencial y libertad de Claude.

Por qué me parece relevante para ti

Porque en Claude Desktop tienes acceso a todo el ecosistema que ya conoces si sigues esta newsletter: Skills, MCPs, SDD desde el primer momento. Es más, puedes:

1. Planificar y clarificar desde el mismo chat del proyecto.

2. Diseñar a través de Claude Design (y exportar lo que has hecho).

3. Construir y desplegar a través del chat con Claude Code.

No estás limitado a un stack ni a un conjunto cerrado de integraciones. Y el modelo que hay detrás es el mismo que usa Lovable, solo que sin la capa intermedia que te recorta las posibilidades.

Tengo ganas de grabar o de hacer un directo. Si tienes ganas de ver el proceso completo desde la ideación con SDD, pasar por Claude Design y terminar cosntruyendo con Claude Code Desktop, dejame un buen comentario y montamos algo 😊

Deja un comentario

¡Y hasta aquí la newsletter de hoy! Si te ha gustado lo que has leído no te olvides de compartirlo 😉

Pol Marzà - AI Product Builder

¿Cómo estás? :)

El jueves pasado estuve en Valencia. Di una charla en NTT Data, organizada por Product Beers Valencia, sobre mí: sobre cómo construyo con IA desde 2023 y cómo ha cambiado por completo mi forma de hacerlo en estos casi 4 años. De programar con ChatGPT y VSCode a orquestar agentes que hacen el 80% del trabajo pesado.

Pero lo interesante no pasó en la charla. Pasó después, con una cerveza en la mano.

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í:

Suscríbete ahora

Hablando con la gente que había venido, una idea salía una y otra vez en distintas conversaciones: construir ya no es el problema. Hoy, levantar un SaaS, una app, una web o un agente está al alcance de muchísima más gente. La barrera técnica, esa que durante años dejó fuera a los no-técnicos, se ha difuminado. Cualquiera con una buena idea y constancia puede tener un producto funcionando en un fin de semana.

¿Y entonces cuál es el problema? El mismo de siempre, solo que se ha movido de sitio: la distribución.

Puedes construir algo brillante y que no lo vea nadie. Lanzas en X, en Product Hunt, en LinkedIn… y tienes muy poco impacto. Porque las redes premian a quien ya tiene audiencia, y la mayoría de los que construimos en solitario tenemos audiencias pequeñas. Un producto técnicamente superior puede morir en el lanzamiento simplemente porque nadie lo vio.

Esa noche, de vuelta en el hostal, no me lo podía quitar de la cabeza.

Y se me ocurrió una idea.

La idea: solos llegamos a mil; juntos, a diez mil

Imagina que lanzas tu proyecto tú solo y tu audiencia es de 1.000 personas. Llegas a 1.000 personas. Punto.

Ahora imagina que diez builders de una comunidad publican sobre tu proyecto el día del lanzamiento. Si cada uno tiene 1.000 seguidores, de repente tu alcance potencial no es 1.000: son 10.000. La comunidad no te suma, te multiplica. Te catapulta.

Esa es toda la filosofía de Swapicorn.

Qué es Swapicorn

Swapicorn es un ecosistema de distribución colaborativa para builders de IA. No es publicidad ni un directorio más donde subir tu link y rezar. Es un sistema de apoyo mutuo, meritocrático y de suma positiva. Lo defino como un “sindicato de creadores”: donde el éxito de uno impulsa al resto.

Funciona con un sistema de créditos llamados Swapis:

• Te registras, conectas tus redes y el sistema te asigna un nivel del 1 al 5 según tu alcance.

• Publicas tu proyecto y le asignas un presupuesto de swapis.

• Otros builders lo promocionan en sus redes y, a cambio, ganan tokens (swapis).

• Tú, a tu vez, ganas swapis promocionando los proyectos de otros.

Es un círculo virtuoso: ayudas a la comunidad y la comunidad te ayuda a ti. Nadie depende de tener ya un público enorme ni de gastar un euro en ads. El mérito y la reciprocidad sustituyen al algoritmo y al presupuesto.

Y lo mejor: cuando alguien promociona tu proyecto, no es un bot ni un anuncio frío. Es otro builder, con su voz y su audiencia real, contándole a su gente lo que has construido.

Lo construí este fin de semana (y eso es parte del mensaje)

Hay algo que me hace gracia y que encaja perfecto con la tesis de la charla: monté Swapicorn entero este fin de semana, construyendo con IA. Lo que antes habría sido un proyecto de meses, hoy es un finde. La parte difícil ya no era hacerlo. La parte difícil sigue siendo que llegue a la gente adecuada.

Así que Swapicorn es, en cierto modo, una solución construida con la propia herramienta que crea el problema. Me parece poético.

Lo lancé hace apenas un par de días, lo he ido enseñando en grupos pequeños y ya hay seis proyectos publicados. Está en beta: puede tener errores, cosas a medio pulir, detalles que mejorar. Cuento con ello.

Esto es para ti si construyes con IA

Si estás leyendo esto y construyes productos (solo o en equipo) y te suena eso de “lo lancé y no lo vio nadie”, Swapicorn es para ti.

Entra, sube tu proyecto y deja que la comunidad lo amplifique. Y si por el camino te encuentras un bug, una fricción o algo que no cuadra, déjamelo en los comentarios: estoy puliendo la plataforma en directo y cada feedback me ayuda a hacerla mejor.

👉 Únete a Swapicorn

Lo vi. Entendí el argumento. Y creo que está equivocado, aunque no por las razones que imaginas.

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í:

Suscríbete ahora

Déjame contarte cómo uso yo el vibe coding, porque creo que ahí está la clave.

Cuando tengo una idea, lo primero que hago no es sentarme a planificar. Lo primero que hago es construirla. Sin estructura, sin documentación y sin pensar demasiado.

Abro Lovable o Claude Code y les describo lo que tengo en la cabeza. En media hora tengo algo que puedo tocar. Algo que funciona más o menos, que tiene agujeros por todos lados y que probablemente tire a la basura en dos días.

Y eso es exactamente lo que quiero.

Porque lo que me da ese prototipo no es código. Me da claridad. Cuando construyes algo rápido y mal:

• Descubres los problemas reales antes de invertir tiempo en resolverlos bien.

• Descubres que el flujo que imaginabas no tiene sentido cuando lo usas.

• Que la funcionalidad que creías central resulta secundaria.

• Que hay un problema técnico concreto que no habías visto desde la descripción.

Después de ese prototipo, lo tiro. Y construyo de nuevo, esta vez con SDD. Pero ya no estoy construyendo a ciegas. Sé lo que quiero que haga la aplicación. Sé los retos a los que me voy a enfrentar. Tengo criterio para tomar decisiones porque ya he tropezado con los problemas una vez.

El vibe coding no es una metodología de desarrollo. Es una metodología de exploración. Y los que dicen que ha muerto están comparando dos cosas que no compiten entre sí.

Los datos que citan esos vídeos son reales: la gente que intentó lanzar productos serios solo con vibe coding se encontró con código frágil, deuda técnica imposible de gestionar y aplicaciones que no escalaban. Pero ese no es un problema del vibe coding; es un problema de usarlo para lo que no fue pensado.

Para recapitular antes de cerrar:

1. Vibe codea tu idea → Sin pensar demasiado. El objetivo no es el código, es entender si la idea tiene sentido cuando la tocas con las manos.

2. Clarifica tus hallazgos → Antes de tirar el prototipo, documenta lo que has aprendido. Qué funcionó, qué no, qué problema real has descubierto debajo del problema que creías tener.

3. Redacta los docs en SDD → Ahora sí. Con ese conocimiento encima de la mesa, define la arquitectura, el modelo de datos, el comportamiento esperado. Ya no estás especulando, estás describiendo algo que entiendes.

4. Construye con Claude Code → Con los docs como contexto, el agente tiene todo lo que necesita para generar código que no tendrás que tirar.

Hablo en pasado porque esto acaba de cambiar.

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í:

Suscríbete ahora

Para entender qué ha pasado, primero necesitas saber por qué estaba roto.

Cuando visitas una web, tu navegador recibe un documento HTML y lo muestra. Pero hay dos formas de generar ese documento:

• SSR (Server-Side Rendering): el servidor te lo manda ya construido, con todo el contenido dentro.

• SPA (Single Page Application): el servidor te manda un esqueleto casi vacío y un montón de JavaScript que se ejecuta en tu navegador para construir la página.

Tú, como usuario, no notas la diferencia. Ves el título, el texto, las imágenes. Todo normal. El problema es que los robots no funcionan como tú.

Cuando Google rastrea una web, manda un programa que descarga el HTML inicial y lo lee tal cual. En una web construida con Lovable, ese HTML inicial era básicamente un <div> vacío (era una SPA). El contenido real lo generaba React después, en tu navegador, pero para cuando eso ocurría el robot ya se había ido. Lo mismo le pasaba a ChatGPT, a Perplexity, a cualquier herramienta que intentase leer el contenido de tu app a partir de su URL.

Llevaba meses señalando esto en LinkedIn cada vez que el tema salía. Si necesitabas posicionamiento, recomendaba Astro, Next.js, o trabajar directamente con Claude Code. Herramientas que generan el HTML completo en el servidor (SSR) antes de mandártelo, para que cuando llegue el robot encuentre algo que leer.

Lovable acaba de hacer exactamente eso. Los proyectos nuevos se construyen sobre TanStack Start, un framework con renderizado en el servidor nativo. Las páginas llegan al navegador ya completas. Google las puede leer desde el primer momento. ChatGPT también. Y los proyectos existentes reciben automáticamente un sistema de snapshots estáticos que hace accesible el contenido a los crawlers sin que tengas que migrar nada ni tocar ningún ajuste.

Es un cambio técnico, sí. Pero lo que representa va más allá de la técnica. Lovable lleva tiempo siendo la herramienta favorita para construir prototipos rápidos, pero con este movimiento está diciendo que quiere ser algo más: una plataforma desde la que lanzar productos reales, que compitan, que el mundo pueda encontrar.

Hoy el post ha sido algo más cortito, con un par de enlaces a las definiciones de SSR y SPA en nexy.ai y otros enlaces a las webs de frameworks. ¿Qué te parece este formato? Déjame tu opinión en los comentarios :)

Por cierto, el próximo jueves 28 de mayo estaré en Valencia dando una charla con los compañeros de Product Beers Valencia. Explicaré como ha sido mi camino de AI CODING, desde mis inicios con ChatGPT en noviembre de 2022 hasta Claude Code. Hablaré de la mentalidad maker más que de las herramientas, explicaré mi experiencia construyendo, desde los proyectos Frankenstein hasta el SDD.

Si estás por Valencia, ¡apúntate que las reservas están volando!

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í:

Suscríbete ahora

Hoy hablaremos de seguridad en nuestros desarrollos 🤓

Te hago un pequeño resumen por si quieres ir directamente a ese apartado que más te interese:

• Las imperdibles— Variables de entorno, RLS en Supabase y rotación de keys: lo que ninguna herramienta puede compensar si lo ignoras.

• /security-review en Claude Code — El comando nativo de Anthropic que audita tu código antes de cada deploy, sin configuración.

• Aikido: escaneo continuo — Conecta tu repositorio y vigila vulnerabilidades en segundo plano, gratis hasta 10 repos.

• Bonus: pentesting en Lovable — Agentes que atacan tu app en vivo para encontrar lo que el análisis estático no ve.

Ahora sí, ¡empezamos!

1. Las imperdibles

Antes de hablar de herramientas, hay decisiones de arquitectura que ningún escáner puede compensar si las ignoras desde el principio.

Nunca hardcodees credenciales en el código. Las API keys, tokens de base de datos y secrets no deben estar escritos en ningún archivo de tu repositorio, ni en comentarios, ni en archivos de configuración que subes a GitHub. Esto parece obvio hasta que ves a alguien publicar un repo con las keys de Stripe expuestas.

La alternativa es usar variables de entorno. En Vercel las gestionas desde el panel del proyecto (Settings → Environment Variables). En Supabase tienes las claves de servicio accesibles desde Project Settings → API. Tu código lee esas variables pero nunca las contiene.

Activa Row Level Security en Supabase desde el inicio. Si construyes con Supabase y no activas RLS en tus tablas, cualquier usuario autenticado puede leer (o modificar) los datos de cualquier otro usuario. No es una vulnerabilidad avanzada, es la configuración por defecto cuando creas una tabla sin políticas.

Actívalo al crear la tabla, no después. Añadirlo retroactivamente cuando ya tienes datos y lógica construida es más costoso y más fácil de hacer mal.

Rota las keys si sospechas una exposición. Si en algún momento una key estuvo en un commit, en un mensaje de chat, o en cualquier lugar fuera de las variables de entorno, invalídala y genera una nueva. El tiempo que tardas en rotar es menor que el daño potencial.

2. Auditoría con Claude Code: el comando /security-review

Claude Code incluye por defecto un slash command mantenido por Anthropic llamado /security-review. No hay que instalarlo ni configurarlo: está ahí desde el primer momento.

Lo que hace es analizar los cambios pendientes en tu codebase buscando vulnerabilidades reales y explotables. No es una búsqueda por patrones superficiales: examina el código en contexto, entiende qué hace cada parte y filtra los falsos positivos para darte solo hallazgos que merecen atención.

Las categorías que cubre:

• Inyección de SQL, comandos y otros vectores de inyección

• Problemas de autenticación y autorización (escalada de privilegios, bypass de sesiones)

• Exposición de datos sensibles y secrets en el código

• Problemas criptográficos

• Configuraciones inseguras

Cómo usarlo: abre Claude Code en tu proyecto, escribe /security-review y deja que analice. El momento ideal es antes de cada deploy relevante, especialmente si has tocado autenticación, esquema de base de datos o endpoints de API.

También puedes integrarlo en GitHub Actions para que revise automáticamente cada pull request. El repositorio oficial de Anthropic (anthropics/claude-code-security-review) tiene el workflow listo para copiar.

Un par de enlaces de interés:

• Documentación oficial sobre /security-review en el blog de Anthropic.

• Repositorio oficial en Github.

3. Aikido: escaneo continuo del repositorio

/security-review analiza tus cambios de forma manual y bajo demanda. Aikido hace algo diferente: conecta con tu repositorio de GitHub, lo escanea de forma automática cada pocos días y te avisa cuando encuentra algo.

El plan gratuito incluye hasta 10 repositorios, 2 usuarios y escaneo básico. Para un builder individual o un equipo pequeño es suficiente para tener visibilidad continua sin pagar nada.

Lo que escanea en el plan gratuito:

• SCA (Software Composition Analysis): vulnerabilidades conocidas en tus dependencias npm. Las librerías que instalas también tienen CVEs, y Aikido los detecta antes de que alguien los explote.

• SAST (Static Application Security Testing): análisis estático del código buscando patrones de vulnerabilidad.

• Detección de secrets: credenciales que pudieran haberse filtrado en el repositorio.

• Escaneo de cloud: misconfigurations en tu cuenta de Vercel, AWS o GCP si la conectas.

La diferencia respecto a otras herramientas similares es la reducción de ruido. Contextualiza los hallazgos según tu entorno real y descarta los que no suponen un riesgo efectivo. Menos alertas, más señal.

Cómo empezar: entra en aikido.dev, conecta tu cuenta de GitHub y selecciona los repositorios que quieras monitorizar. El primer escaneo tarda entre 1 y 5 minutos.

Bonus track: pentesting con Aikido en Lovable

Si construyes con Lovable, hay una capa adicional disponible desde marzo de 2026: pentesting con IA directamente integrado en el editor.

La distinción importante es que el escáner de seguridad de Lovable (que ya existía) hace análisis estático: lee el código y detecta patrones problemáticos. El pentesting de Aikido hace análisis dinámico: despliega agentes que atacan la aplicación en vivo, como lo haría un atacante real. Prueban flujos de autenticación, intentan acceder a datos de otros usuarios, sondean las APIs.

Las dos cosas son complementarias:

• El estático detecta lo que podría ir mal en el código.

• El dinámico detecta lo que efectivamente se rompe cuando alguien lo intenta.

Para proyectos en Lovable, el precio de lanzamiento es de 100 dólares por test. También hay “Security weekends” gratuitos anunciados puntualmente. El modelo de pago es cómodo: puedes iniciar el pentest sin pagar y solo desbloqueas el informe completo si decides que los hallazgos merecen el coste.

El flujo desde Lovable: Settings → Connectors → App connectors → Aikido. Desde ahí puedes lanzar el test y los hallazgos se sincronizan directamente en tu proyecto para corregirlos sin salir del editor.

El orden lógico

Las tres validaciones no son alternativas, son capas:

1. Las buenas prácticas son el suelo. Sin ellas, nada de lo demás importa.

2. /security-review es la revisión activa antes de cada deploy importante.

3. Aikido es la vigilancia continua en segundo plano.

El pentesting es el siguiente paso cuando el producto ya está en producción y quieres poder demostrar, no solo suponer, que es seguro.

Construir rápido no obliga a construir inseguro. Solo requiere que estas validaciones sean parte del flujo desde el principio, no algo que se añade cuando ya hay un problema.

¡Y hasta aquí la newsletter de esta semana! Espero que no haya sido muy densa.

Lo bueno de todo esto es que, como digo al final, ¡lo puedes empezar a aplicar desde YA! No esperes a que salgan errores.

¡Nos vemos la próxima semana!

Un abrazo.

Antes de nada, discúlpame por no escribir desde principios de mes… Pero hoy si, hoy vamos a hablar de algo que ya adelanté hace unos días en LinkedIn. Hoy vamos a hablar de yoleo.

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í:

Suscríbete ahora

yoleo v1

La primera vez que construí yoleo no tenía ni idea de programar.

2023 acababa de empezar. Unos pocos meses antes había llegado a nuestras vidas la versión comercial de ChatGPT y, con ella, la promesa de poder construir cualquier cosa con la ayuda de la IA. O eso pensaba yo 😅

Pero si, lo construí.

Para esa primera versión solo usé HTML, CSS y JS. El funcionamiento era sencillo: tenías un input (una caja de texto) donde escribías el título de un libro que te había gustado. Luego, por detrás, yo lanzaba una petición a la API de OpenAI (ChatGPT) con un prompt tipo:

“Actúa como un librero y dame 5 libros que tengan relación semántica con {libro}”

Pero esta primera versión tenía dos problemas:

1. ChatGPT alucinaba bastante (se inventaba títulos)

2. ¡ALERTA! La clave API estaba expuesta en el código

El primer problema tenía un pase, no era crítico. Pero el segundo… Ese sí que podía ser un problemón 🙃

Lo intenté ocultar, lo intenté enmascarar, pero si sabías lo que buscabas… No era difícil de encontrar.

yoleo v2

Unos meses más tarde de construir esta primera versión, un compañero de trabajo me presentó a un desarrollador llamado Pablo.

Con él, construí la segunda versión de yoleo. Pablo se encargó de toda la parte de backend y base de datos. Yo me encargué del front y de la dirección de producto.

Juntos fuimos tomando decisiones importantes y resolvimos los problemas de la primera versión:

1. Alucinaciones → Comparábamos cada libro devuelto por ChatGPT con la API de Google Books. Si existía lo mostrábamos al usuario y si no, no.

2. API expuesta → Ahora ya en variables de entorno. Lejos de ojos fisgones.

3. Añadimos la opción de que el usuario se pudiera registrar para tener un historial de sus libros buscados.

Con todo esto, en 2024 presentamos el proyecto en LinkedIn y a alguien le pareció interesante qué y cómo lo habíamos construido, así que nos fuimos para Madrid a presentarlo.

yoleo v3

Y aquí llegamos a la versión actual del proyecto 🥳

¿Qué ha cambiado?

1. Para las peticiones de la API ya no uso (solamente) ChatGPT, sino que uso la API de Openrouter y voy cambiando de proveedores. Al principio empecé con Gemini 2.5 Flash, pero ahora estoy usando Deepseek v3.2 que ofrece resultados parecidos a un coste menor.

2. En la v2 de yoleo usábamos MongoDB. Ahora uso Supabase tanto para almacenar los datos (libros, autores, portadas, preferencias de los usuarios…) como para el OAuth con Google.

3. En un principio, esta versión usaba la search_tool (a través de la API), tanto para buscar libros nuevos como para ofrecer las recomendaciones (en cada ficha se ofrecen hasta 8 libros relacionados), pero era MUY caro. Ahora funciona con embeddings de libros que ya se encuentran dentro de yoleo. Es decir, he vectorizado los 50k libros.

Lo que más me gusta de esta nueva versión es:

• Las portadas → Tenía un problema con ellas, ya que la API de Google Books y la de Open Library, la mitad de las veces no me devolvían la portada del libro en su idioma o directamente no me devolvían nada 🤣 Así que dije “hasta aquí” y, lo que tenía que ser un parche se ha convertido en una de sus señas.

  Las portadas son generadas al vuelo y se toma su main_category como referencia para elegir el color de la portada. Además, también se añade el autor/a, el título y año de publicación.

• Afinidad → Esto es algo que no he encontrado en otras páginas y se trata de mostrarte como de posible es que te guste un libro en función de los libros que hayas valorado o leído previamente. Lo mejor de todo es que no usa IA sino que se basa en los libros que has leído o puntuado. Pura lógica. Puedes desbloquear la afinidad cuando hayas valorado/añadido un mínimo de 5 libros a tu biblioteca 🥰

Hay más cosas y muchas más que espero ir añadiendo (poco a poco) a yoleo.

Y muchas otras cosas que ya existen, pero no puedo explicarlas todas. Así que te dejo que seas tu quien las descubras 🤗 Actualmente la plataforma cuenta con:

Una de las cosas que he decidido hacer en este proyecto es intentar ser lo más transparente posible, tanto en cuanto a los datos de la plataforma (número de libros, autores y usuarios) con contadores dinámicos que encontrarás mientras navegas por yoleo, como lo que me cuesta mantener el proyecto en marcha (lo puedes ver al final de la landing).

De cara a las próximas semanas, me gustaría seguir mejorando la plataforma pero eso solo tendrá sentido si te registras, compartes y le das cariño a yoleo.

¿Hay hueco para otra plataforma de libros?

¿Qué echas de menos en la plataforma actual?

Déjamelo en los comentarios 👇

¡Y hasta aquí la newsletter!

Nos vemos próximamente :)