¡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í:
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:
BBDD
Backend
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?
Si este post te resulta útil, ¿qué te parece si lo compartes? 😜
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:
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”).
A quién se lo vas a enseñar y qué decisión tomará esa persona al verlo (invertir, usarlo, darte feedback).
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é :)
Vaya pues tengo mucho que decir pero lo primero es:
Si ya tienes claridad de que es lo que quieres construir (como indicas en tu post)
Por qué no usar directamente Spec-Driven Development?
Me gusta mucho esa distinción entre construir desde dentro cuando el dominio ya está claro y empezar por fuera cuando lo que todavía estás validando es si merece la pena construirlo.
Muchas veces el error no está en la herramienta, sino en aplicar demasiado pronto una arquitectura sólida a una idea que aún necesitaba poder morir barato.