MVP: la primera versión real de tu producto

Qué es un MVP y qué no

Un MVP es la versión más pequeña del producto que ya resuelve el problema completo para alguien. No es una demostración, no es una pantalla bonita sin nada detrás, y no es el producto final con la mitad de las funcionalidades apagadas.

La confusión sale cara. Quien pide un prototipo y recibe un MVP paga de más. Quien pide un MVP y recibe un prototipo descubre a los tres meses, cuando aparecen los primeros usuarios de verdad, que hay que construirlo todo otra vez.

Por qué la arquitectura importa tanto al principio

Si el modelo de datos y la arquitectura parten bien, los meses siguientes se dedican a construir funcionalidades. Si parten mal, se dedican a arreglar lo construido.

El ejemplo más común es el de la cuenta única. Un producto que nace pensando que cada persona usa el sistema por su cuenta y después necesita equipos, empresas o roles, no agrega una tabla: reescribe cada consulta, cada permiso y cada pantalla. Es la diferencia entre una decisión de una tarde y un mes de trabajo. Está desarrollada en multiempresa desde el principio.

Qué incluye

• Modelo de datos y arquitectura definitivos. Diagrama de entidades y decisiones de tecnología y hospedaje tomadas para los próximos años.
• Cuentas, sesiones y permisos. Registro, ingreso, recuperación de contraseña y control de qué puede ver y hacer cada tipo de usuario.
• El flujo principal completo. De la primera pantalla al objetivo del usuario, terminado lo suficiente para presentarlo sin tener que explicar qué falta.
• Pagos y suscripciones, cuando el modelo de negocio necesita cobrar desde el comienzo.
• Analítica base. Los eventos que importan, instrumentados, para que las primeras decisiones de producto se tomen mirando datos.
• Traspaso. Repositorio documentado y una sesión de entrega cuando aparezca el primer desarrollador interno.

El diseño va dentro, no aparte

El diseño de producto no se contrata por separado ni llega después: es parte de construir el MVP. Antes de escribir código hay que decidir qué pantallas existen, en qué orden aparecen y qué puede hacer cada tipo de usuario en cada una. Eso es diseño, y hacerlo mal cuesta lo mismo que hacer mal la arquitectura.

Lo que se define:

• Los flujos. Del registro al momento en que el producto cumple su promesa, paso a paso, con los caminos que se pueden torcer.
• Las pantallas que importan. No todas: las que sostienen el flujo principal. El resto se resuelve con los mismos componentes.
• Un sistema de componentes, para que agregar una pantalla nueva sea combinar piezas que ya existen y no dibujar desde cero.
• Los estados que nadie recuerda: la lista vacía la primera vez, el error de conexión, el proceso a medio terminar. Son los que se descubren en producción cuando no se diseñaron.

Lo que no se hace es una maqueta bonita que después haya que traducir a código. El diseño y la construcción avanzan juntos, sobre los mismos componentes.

Cuándo tiene sentido

Ya sabes que el problema existe. Idealmente porque hablaste con quienes lo tienen, o porque una landing de validación recogió señales concretas.

Necesitas algo funcionando para levantar capital. Una demostración en vivo con datos reales pesa distinto que una presentación.

El software es el negocio, no un accesorio del negocio.

Cuándo no

Si todavía no sabes si alguien quiere esto, un MVP es la forma cara de averiguarlo. Lo que corresponde primero es la evaluación previa, que cuesta una fracción y responde la misma pregunta.

Si el producto se resuelve con herramientas sin código y no tiene lógica propia, construirlo a medida es gastar de más.

Qué queda al terminar

El producto en operación con dominio y certificado, el repositorio completo, la documentación de la arquitectura y los accesos a la infraestructura. Todo a nombre de la startup. Está detallado en de quién es el código y la infraestructura.

Si lo que sigue es crecer sobre esa base, el trabajo continúa como plataforma SaaS. Si lo que hace falta es sostener lo que ya está operando, es mantención y evolución.