Desarrollo database-first:diseña antes de hacer el prompt

El desarrollo database-first consiste en diseñar tu base de datos antes de escribir una sola línea de código de aplicación. Las dos semanas que dediques a diseñar el sistema antes de construirlo te ahorrarán dos meses de refactorización durante la construcción. No es una hipótesis: es un problema de aritmética que se ha demostrado en todas las bases de código que he visto, incluida la mía.

Las dos semanas más importantes de la construcción de FIKR Space fueron las que dediqué a diseñar el esquema de la base de datos antes de escribir código de aplicación. La mayoría asiente a esa frase y luego la ignora. Esta es la versión práctica: las tres cosas que significa de verdad "diseñar la arquitectura" y el calendario de construcción que sigue cuando ya lo has hecho.

Desarrollo database-first: por qué la tentación es la trampa

Te tentará, en cuanto termines la validación, abrir Claude o Cursor y ponerte a construir. Querrás la dopamina de ver crecer el código. Querrás enseñarle una captura a tu pareja al final del fin de semana. Resístete.

Empezar a programar antes de diseñar la base de datos es el error maestro: todas las demás trampas de la construcción vienen de él. Te sientes productivo el primer día porque la IA genera pantallas, pero la base que hay debajo es fluida, y cada semana que la base se mueve, todo lo construido encima hay que rehacerlo. Ese bucle acelerado de retrabajo es exactamente como la trampa del vibe coding se cierra sobre quienes se sentían imparables en la primera semana.

Paso 1: diseña la base de datos, en papel

Enumera todas las entidades de tu producto. Usuarios. Empresas. Suscripciones. Los sustantivos centrales que sean. Luego enumera las relaciones: un usuario pertenece a una empresa, una empresa tiene muchos usuarios, una suscripción pertenece a una empresa y registra el uso.

Dibújalo en papel. Sí, papel. El acto de dibujar te hace pensar en los bordes que se te escaparían en un diseño solo mental. Cuando las cajas y las flechas dejan de cambiar, tienes un esquema. Después describe las entidades con claridad a Claude y él escribirá el SQL en veinte minutos. Ya tienes tu base.

Paso 2: define los límites de los servicios

¿Cuáles son las operaciones principales que realiza tu sistema? Registrarse. Procesar un pago. Generar un informe. Enviar una notificación. Cada una es un servicio: una pieza autónoma del sistema con un trabajo definido. Define las entradas y salidas de cada servicio antes de escribirlo.

Suena burocrático. No lo es. Es la diferencia entre un sistema que puede evolucionar y uno que se calcifica a los tres meses.

Paso 3: recorre los flujos de usuario

Recorre las tres cosas más importantes que hará un usuario con tu producto: registrarse, completar su primera acción valiosa, renovar su suscripción. Esboza cada flujo como una secuencia de pantallas o interacciones; no diseñes todavía las pantallas, solo la secuencia. Buscas los lugares donde el flujo se rompe o donde has supuesto algo que no será cierto.

Cuando la base de datos, los servicios y los flujos tienen sentido en papel, y lo siguen teniendo tras volver a mirarlos con ojos frescos un día después, tienes una arquitectura. Ya puedes construir.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

El calendario de ocho semanas que sigue

Arquitectura primero no es más lento. Es lo que hace rápida la parte rápida. Este es el calendario que desbloquea, con entre cuatro y ocho horas semanales de construcción concentrada:

Al final de la semana seis, el producto tiene funcionando sus tres o cuatro flujos centrales: registrarse, hacer lo principal, que se te cobre, volver mañana y repetirlo. Esto es lo que una persona puede hacer en 2026 y que diez personas no podían hacer en 2020 por ningún dinero, y cada una de esas funcionalidades semanales empieza con un briefing escrito, no con un prompt esperanzado. Eso es el método PRP, y solo funciona porque la arquitectura que hay debajo ha dejado de moverse.

No dejes que la IA sea el arquitecto

Claude es un implementador brillante y un arquitecto mediocre. Pregúntale "¿esto debería ser una tabla aparte o una columna JSON?" y te dará una respuesta: normalmente buena, a veces mala, de vez en cuando genial. El problema es que no tienes forma de evaluar en qué caso estás si no tienes tu propio criterio arquitectónico. Desarróllalo a propósito: mira cómo estructuran sus sistemas otros productos, trabaja los compromisos en papel y escribe la arquitectura antes de pedirle a Claude que la implemente.

Las decisiones de arquitectura son tuyas. Las decisiones de implementación son de Claude. Mantén esa frontera y la base de código mejora con el tiempo; difúmala y se deteriora.

Si estás en esta etapa ahora mismo, esta es tu semana: dedica tres tardes a entidades y relaciones. Dibuja el esquema en papel. Refínalo. Pídele a Claude que genere el SQL. Compruébalo recorriendo tus tres flujos de usuario más importantes y viendo si el esquema los soporta limpiamente. No escribas todavía código de aplicación. El domingo por la noche tendrás un esquema del que te fías y una lista de las cuatro a seis funcionalidades centrales que construirás durante las próximas seis semanas. Aburrido. Lento. Vale cada hora.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Qué es el desarrollo database-first?

Construir el modelo de datos antes que cualquier código de aplicación: enumeras las entidades y relaciones de tu producto, las refinas en papel hasta que dejan de cambiar y solo entonces generas el esquema y empiezas a construir funcionalidades. La base de datos es el cimiento, y todo lo demás se construye encima, así que tiene que dejar de moverse primero.

¿Cuánto tiempo dedicar a la arquitectura antes de programar?

Dos semanas: base de datos, límites de servicios y flujos de usuario. Esas dos semanas te ahorran dos meses de refactorización durante la construcción, porque las funcionalidades construidas sobre una base estable no hay que rehacerlas cada vez que la base se mueve.

¿Puede la IA diseñar mi base de datos?

La IA puede escribir el esquema: describe tus entidades con claridad y Claude produce el SQL en veinte minutos. Pero no debería tomar las decisiones de diseño. Claude es un implementador brillante y un arquitecto mediocre: las entidades, las relaciones y los compromisos son decisiones tuyas que tomas antes de escribir el prompt.

No soy técnico: ¿puedo diseñar un esquema de verdad?

Sí, porque la parte difícil no es técnica. Es enumerar los sustantivos de tu negocio (usuarios, empresas, suscripciones) y cómo se relacionan, algo que conoces mejor que cualquier desarrollador. Cajas y flechas en papel. Cuando dejan de cambiar, el diseño está hecho y la IA se encarga de traducirlo a SQL.