Vibe Coding: cómo definir los datos de un MVP antes de agregar funciones
Una persona emprendedora puede comenzar un MVP describiendo una pantalla a una herramienta de inteligencia artificial: “crea una vista para reservar una clase”. Después pide un calendario, un panel de administración, notificaciones y pagos. Cada pantalla parece funcionar por separado, pero pronto aparecen problemas: reservas duplicadas, estados contradictorios, clientes repetidos y datos que no coinciden entre una vista y otra.
El problema no suele estar en la velocidad de la IA para generar interfaces. Está en que la aplicación comenzó a crecer sin una definición clara de la información que debe guardar y de las reglas que debe respetar.
Antes de pedir otra función, conviene poder responder preguntas sencillas: qué datos existen, cómo se relacionan y qué situaciones no deberían ocurrir. No es necesario convertirse en especialista en bases de datos. Sí es necesario describir el funcionamiento real del negocio con suficiente precisión para que la IA no tenga que inventarlo.
Por qué el modelado de datos importa en un MVP
El modelado de datos es la forma de representar la información principal de una aplicación, sus relaciones y las reglas que la mantienen coherente. En un MVP, ese modelo puede ser pequeño. Lo importante es que sea explícito.
Por ejemplo, una aplicación de reservas podría necesitar inicialmente:
- Personas que realizan reservas.
- Servicios o clases disponibles.
- Horarios concretos.
- Reservas asociadas a una persona y a un horario.
- Un estado para saber si una reserva está pendiente, confirmada o cancelada.
Si estos conceptos no se definen, una herramienta de IA puede crear un campo llamado estado en una pantalla, otro llamado estatus en una tabla y un tercero llamado confirmado en otra parte de la aplicación. Visualmente pueden parecer equivalentes, pero para el sistema podrían representar cosas distintas.
La consecuencia es que cada nueva función debe compensar las ambigüedades anteriores. Una pantalla consulta un dato, otra lo modifica y una tercera interpreta el valor de otra manera. El MVP sigue mostrando avances, pero se vuelve difícil saber qué comportamiento es correcto.
Empieza por identificar las entidades principales
Una entidad es algo relevante para el negocio sobre lo que necesitas guardar información. Puedes encontrarla preguntando: “¿qué objetos existen aunque todavía no haya una pantalla para ellos?”.
En el ejemplo de reservas, las entidades podrían ser:
- Cliente: la persona que solicita una reserva.
- Servicio: aquello que se puede reservar, como una clase o una consulta.
- Horario: una fecha y una hora disponibles para un servicio.
- Reserva: la solicitud que vincula a un cliente con un horario.
Esta separación evita guardar toda la información en un único registro difícil de interpretar. Una reserva no debería tener que repetir permanentemente el nombre del cliente, el nombre del servicio, la fecha y todos los detalles del horario si esos datos ya pertenecen a otras entidades.
Una pregunta práctica para cada entidad
Para cada concepto, intenta describir qué información mínima necesita. Por ejemplo, un cliente podría tener nombre y correo electrónico; un servicio, nombre y duración; un horario, fecha y hora de inicio; y una reserva, referencias al cliente y al horario, además de su estado.
La palabra mínima es importante. Si el MVP todavía no necesita guardar preferencias de idioma, dirección de facturación o historial detallado, esos campos pueden esperar. Definir los datos no significa diseñar todo el producto futuro, sino establecer una base coherente para la primera versión.
Define las relaciones entre los datos
Las entidades no viven aisladas. Las relaciones explican cómo se conectan entre sí y ayudan a evitar duplicaciones.
En una aplicación de reservas, una relación sencilla podría describirse así:
- Un cliente puede tener varias reservas.
- Un servicio puede tener varios horarios.
- Un horario pertenece a un servicio.
- Una reserva corresponde a un cliente y a un horario.
Esta descripción es más útil que decir simplemente “crea una pantalla de reservas”, porque aclara qué debe ocurrir cuando se consulta o modifica la información.
También permite detectar decisiones que suelen quedar ocultas. Por ejemplo: ¿un horario puede tener una sola reserva o varias? Si se trata de una clase grupal, quizá tenga un límite de participantes. Si es una consulta individual, probablemente solo pueda asignarse a una persona.
La respuesta cambia las reglas del sistema. Una aplicación que no distingue estos casos puede permitir reservas incompatibles o mostrar disponibilidad incorrecta.
Evita repetir información sin una razón clara
Si la reserva guarda el nombre del cliente y el cliente también tiene un nombre, ¿qué sucede cuando la persona lo cambia? ¿Cuál de los dos valores debe mostrarse? Si el nombre del servicio se copia en cada reserva, ¿hay que actualizar todas las reservas cuando el servicio cambia?
En ocasiones una copia histórica es válida. Por ejemplo, una factura puede conservar el nombre del servicio tal como estaba al momento de la compra. Pero esa decisión debe ser intencional. La duplicación accidental genera contradicciones; la duplicación planificada puede responder a una necesidad del negocio.
Convierte las reglas del negocio en decisiones explícitas
Las reglas de negocio son condiciones que la aplicación debe respetar. Son especialmente importantes cuando se trabaja con IA, porque una instrucción ambigua permite que la herramienta complete los detalles de distintas maneras.
Para el MVP de reservas, algunas reglas podrían ser:
- Un cliente no puede tener dos reservas para el mismo horario.
- No se puede reservar un horario cancelado.
- Una reserva confirmada ocupa una plaza disponible.
- Una reserva cancelada deja de ocupar esa plaza.
- Solo una persona autorizada puede cambiar ciertos estados.
Estas reglas no son únicamente detalles técnicos. Representan decisiones del producto. Si no están escritas, alguien tendrá que inferirlas al construir cada nueva función.
Usa estados con significados claros
Los estados suelen causar problemas cuando se crean sin una definición precisa. Por ejemplo, “pendiente”, “activa”, “aprobada”, “completada” y “confirmada” podrían significar cosas diferentes para distintas personas.
Un modelo inicial podría definir:
- Pendiente: la solicitud fue creada, pero todavía no está confirmada.
- Confirmada: el sistema o una persona autorizada aceptó la reserva.
- Cancelada: la reserva ya no debe considerarse vigente.
- Completada: el horario ocurrió y el servicio fue realizado.
También conviene decidir qué cambios están permitidos. ¿Una reserva cancelada puede volver a confirmarse? ¿Una reserva completada puede editarse? No todos los estados deben poder transformarse libremente en cualquier otro.
Qué ocurre cuando el modelo es confuso
Imagina que la aplicación comienza con una lista de reservas. Después se agrega un calendario y, más tarde, un panel para que el administrador confirme solicitudes. Si cada pantalla interpreta los datos de manera distinta, pueden aparecer situaciones como estas:
- La lista muestra una reserva como confirmada, pero el calendario la trata como pendiente.
- Una persona puede crear dos reservas porque no existe una regla que impida duplicados.
- La cancelación elimina el registro en una pantalla, pero deja una reserva activa en otra.
- Un horario aparece disponible porque el sistema cuenta solo las reservas confirmadas, aunque las pendientes también deberían bloquear temporalmente el lugar.
- El nombre de un cliente cambia en su perfil, pero conserva un valor antiguo en otras vistas.
Agregar más instrucciones a la IA no siempre corrige estos problemas. Si la estructura de datos sigue siendo ambigua, cada corrección puede resolver un caso y crear otro. El coste aparece como retrabajo, decisiones contradictorias y funciones que dependen demasiado de excepciones.
Cómo describir el modelo antes de pedir otra pantalla
Una forma práctica de trabajar es crear una breve ficha del MVP antes de solicitar nuevas funciones. No tiene que ser un documento técnico extenso. Debe ser lo bastante claro para que otra persona pueda entender qué información existe y qué está permitido hacer.
Plantilla de definición inicial
- Objetivo: qué problema resuelve la aplicación.
- Entidades: qué objetos principales deben existir.
- Datos de cada entidad: qué campos son necesarios y cuáles son obligatorios.
- Relaciones: cómo se conectan las entidades.
- Estados: qué valores puede tener cada proceso.
- Transiciones: qué cambios de estado están permitidos.
- Reglas: qué situaciones no deben ocurrir.
- Acciones: quién puede crear, modificar, cancelar o consultar cada dato.
Con esa base, una solicitud a la IA puede ser mucho más precisa: “Agrega una vista de calendario para mostrar los horarios de un servicio. Cada horario pertenece a un único servicio. Una reserva cancelada no debe bloquear disponibilidad. No permitas que un cliente tenga dos reservas confirmadas para el mismo horario”.
La herramienta seguirá necesitando decisiones de implementación, pero ya no tendrá que inventar las reglas principales del negocio.
Qué conviene mantener simple en un MVP
Definir los datos no significa construir una arquitectura compleja desde el primer día. Para un MVP pequeño, puede ser razonable utilizar pocas entidades, un conjunto limitado de estados y una única aplicación con una base de datos adecuada al alcance del producto.
No siempre es necesario comenzar con microservicios, eventos o múltiples almacenes de datos. Esas alternativas pueden ser útiles en contextos concretos, pero también agregan coordinación, operación y puntos de fallo. La prioridad inicial es que la información principal sea consistente y fácil de entender.
También conviene evitar dos extremos:
- Modelar demasiado pronto: diseñar cada posibilidad futura antes de comprobar si el producto resuelve una necesidad real.
- Modelar demasiado poco: guardar valores ambiguos y confiar en que las pantallas resolverán las diferencias.
Un buen punto de partida es modelar lo que afecta directamente al flujo principal del usuario y dejar documentadas las decisiones que todavía no están resueltas. Una duda explícita es más segura que una regla inventada accidentalmente.
La decisión que debes tomar antes de agregar funciones
En un MVP construido con Vibe Coding, la velocidad de generación puede hacer que una nueva pantalla parezca el siguiente paso lógico. Sin embargo, cada función modifica o consulta datos existentes. Si esos datos no tienen una estructura clara, el producto puede crecer en apariencia mientras pierde coherencia internamente.
El aprendizaje principal es sencillo: dirigir a la IA no consiste solo en describir interfaces. También implica explicar las entidades, sus relaciones, los estados y las reglas que no deben romperse.
Antes de pedir otra pantalla a la IA, describe qué datos existen, cómo se relacionan y qué reglas no deberían romperse. Esa práctica reduce ambigüedades y te ayuda a decidir qué debe incluir realmente tu MVP, sin obligarte a convertirte en especialista en bases de datos.
Si quieres desarrollar este criterio con acompañamiento práctico, el curso de Vibe Coding de Mentores Tech puede ayudarte a pasar de una idea de producto a instrucciones más claras, decisiones técnicas comprensibles y un MVP más consistente.
