Qué decidir antes de construir un MVP

Un MVP no es una versión reducida de cada idea de tu hoja de ruta. Es el producto útil más pequeño que permite a un grupo definido de personas completar un flujo de trabajo importante y le da al equipo evidencia para la siguiente decisión.

Esa palabra, evidencia, merece una pausa.

El análisis de CB Insights sobre por qué fracasan las startups (se abre en una pestaña nueva), publicado en marzo de 2026, examinó 431 empresas financiadas con capital riesgo que cerraron públicamente desde 2023. Halló falta de capital en el 70 % de los casos y mal encaje producto-mercado en el 43 %.

Su observación más útil es sobre cuándo ocurren los fallos de encaje: «dos tercios de los fallos de encaje producto-mercado fueron empresas en fase inicial que nunca encontraron mercado».

El dinero es cómo termina. No aprender lo bastante rápido suele ser el porqué. El mismo principio vale para una herramienta interna de negocio: su primera versión debe demostrar que un flujo de trabajo importante funciona mejor.

Así que la primera versión no es una demostración de tu ambición. Es un instrumento para averiguar algo. Las decisiones que siguen determinan si puede hacerlo.

Lo que un MVP no es

Tres malentendidos causan casi todo el daño, y conviene nombrarlos antes de empezar a planificar:

• Una versión barata del producto completo. Bajar la calidad en todas partes te deja algo que nadie puede juzgar. Recorta el alcance en su lugar, y construye bien lo que quede.
• Un prototipo. Un prototipo responde a una pregunta de diseño y luego se descarta. Un MVP es software real con usuarios reales, y tiene que ser mantenible.
• Una arquitectura definitiva. La primera versión debe poder cambiar. Las decisiones caras de revertir merecen más reflexión que las que no lo son.

La pregunta útil no es «¿qué es lo mínimo que podemos construir?». Es «¿qué es lo mínimo que podemos construir que aun así nos enseñe algo sobre lo que actuaríamos?».

¿Deberías desarrollar a medida siquiera?

Antes de acotar un desarrollo a medida, conviene preguntarse si ya lo necesitas.

El software a medida es la respuesta correcta cuando tu flujo de trabajo es realmente específico, cuando necesitas ser dueño del resultado o cuando las herramientas de mercado no pueden conectarse como funciona tu negocio.

Suele ser la primera respuesta equivocada cuando una herramienta no-code, una hoja de cálculo o un producto existente te dejarían probar la misma hipótesis esta semana.

Una secuencia útil es validar la demanda con lo más barato que funcione y después desarrollar a medida cuando sepas qué partes lo necesitan de verdad.

Muchos productos exitosos empiezan como un proceso manual o un conjunto de herramientas ensamblado. Solo se convierten en software a medida allí donde ese ensamblaje empieza a doler.

Desarrollar a medida demasiado pronto gasta tu presupuesto en demostrar algo que una prueba mucho más barata podría haberte dicho. Hacerlo demasiado tarde te deja peleando con herramientas que ya no encajan.

Responde a eso con honestidad antes de empezar a definir el alcance, no después.

Empieza por el flujo de trabajo del usuario

Antes de hablar de tecnología, describe quién usará el producto, en qué situación está y qué tarea necesita terminar. Si eso queda vago, lo vago te acompaña a cada pantalla y cada función.

Escribe el flujo principal como una secuencia corta. Por ejemplo: un cliente envía una solicitud, alguien del equipo la revisa, el sistema registra la decisión y ambas partes ven el siguiente paso.

El Government Digital Service británico lo formaliza como una fase de descubrimiento. Su manual de servicios (se abre en una pestaña nueva) es tajante sobre el orden: «antes de comprometerte a construir un servicio, tienes que entender el problema que hay que resolver».

Sugiere entre cuatro y ocho semanas como duración típica de ese descubrimiento, que termina con una decisión explícita sobre si existe siquiera un servicio viable.

Una investigación corta y acotada con un go/no-go real es más barata que una construcción que descubre lo mismo en el quinto mes.

Define qué entra en el alcance

Después separa lo imprescindible de lo útil más adelante. Inicio de sesión, permisos, pagos, notificaciones, informes, integraciones y herramientas de administración pueden importar todos, pero la primera versión no los necesita todos al mismo nivel de detalle.

Un buen alcance tiene un motivo para cada función. Mantén una función en la primera versión si cumple al menos una de estas pruebas:

1. el primer usuario no puede completar el flujo principal sin ella
2. reduce un riesgo de entrega que ya has identificado
3. da al equipo el control que necesita desde el primer día
4. dejarla fuera obligaría a reescribir en vez de añadir

Si una función no cumple ninguna, es una decisión posterior y no un recorte. Registrarlo así suele desactivar la discusión sobre quitarla.

Decide cómo sabrás que funcionó

Antes de empezar a construir, acordad qué resultado justificaría continuar, cambiar de rumbo o parar. Sin eso, cualquier desenlace parece alentador.

Elige señales que puedas observar en las primeras semanas de uso real, no las que necesitan un año de datos:

• la gente completa el flujo principal sin que la lleven de la mano
• vuelven sin que se les recuerde
• el trabajo manual que el producto sustituyó baja de forma clara
• alguien pide la siguiente función en vez de un arreglo básico

Escribe qué esperas ver y para cuándo. Comparar eso con lo que ocurre es todo el sentido de publicar pronto.

Escribe qué significa «terminado»

Define qué significa «funciona» antes de empezar el desarrollo. Usa criterios de aceptación observables: el usuario puede enviar una solicitud, la persona adecuada puede revisarla y el sistema registra el resultado correctamente.

Las orientaciones del GDS sobre la escritura de historias de usuario (se abre en una pestaña nueva) describen los criterios de aceptación como «una lista de resultados que usas como lista de comprobación para confirmar que tu servicio ha hecho su trabajo», cada uno formulado en la forma está hecho cuando… — un enunciado.

El valor está en que pueda comprobarlo alguien que no lo construyó.

A nivel de la versión, The Scrum Guide (se abre en una pestaña nueva) define la Definition of Done como «una descripción formal del estado del incremento cuando cumple las medidas de calidad requeridas para el producto».

Practiques Scrum o no, la idea viaja. Un listón de calidad acordado y escrito impide que «terminado» signifique algo distinto para cada persona de la conversación.

Fija las reglas de datos antes del esquema

Decide qué información debe guardar el producto y quién puede acceder a ella. Privacidad, permisos, conservación, copias de seguridad y necesidades de auditoría son más fáciles de planificar antes de que existan las primeras tablas e integraciones.

En productos que tratan datos personales de personas en la UE, hacerlo en ese orden es la ley, no una preferencia.

Las orientaciones de la Comisión Europea sobre protección de datos desde el diseño y por defecto (se abre en una pestaña nueva) describen medidas que se aplican desde las primeras etapas del diseño del tratamiento, con valores por defecto fijados para que «los datos personales se traten con la máxima protección de la privacidad».

El Comité Europeo de Protección de Datos adoptó unas directrices sobre el artículo 25 (se abre en una pestaña nueva) en versión final en octubre de 2020, por si necesitas la posición detallada del regulador.

En la práctica es una lista corta que conviene escribir: qué recoges, para qué, quién puede verlo, cuánto tiempo lo guardas y cómo alguien consigue que se borre.

Responder a eso antes de diseñar la base de datos cuesta mucho menos que añadirlo después.

Elige tecnología e IA con cuidado

Elige la tecnología en torno al producto y sus restricciones. Un framework moderno puede encajar bien, pero la mejor elección depende de los usuarios, los datos, las integraciones, las necesidades de entrega y las personas que mantendrán el software.

La IA merece la misma disciplina. Decide si sostiene el flujo principal, qué pasa cuando su salida es errónea y cómo puede una persona revisarla o corregirla antes de tratarla como un requisito de producto.

Ahora hay motivos medidos para tener cuidado. El 2025 DORA report (se abre en una pestaña nueva), basado en respuestas de casi 5.000 profesionales de la tecnología, informa de que «la adopción de IA sigue teniendo una relación negativa con la estabilidad de la entrega de software».

Producir más rápido sin pruebas y revisión sólidas no se acumula en entregas más rápidas. Se acumula en retrabajo.

Planifica revisiones, accesos y traspaso

Planifica los puntos de revisión antes de la primera línea de código. Demos cortas, una lista de tareas compartida y decisiones escritas donde todos las vean permiten cambiar de rumbo mientras cambiar de rumbo aún sale barato.

La Oficina de Rendición de Cuentas del Gobierno de EE. UU. plantea el argumento del riesgo en su Agile Assessment Guide (se abre en una pestaña nueva): la entrega incremental con evaluación continua «puede reducir los riesgos de financiar un programa que fracasa o produce tecnología obsoleta».

Acordad propiedad y accesos desde el principio. El proyecto debe tener un repositorio de código claro, entornos documentados, una ruta de despliegue acordada y un plan de traspaso que no dependa de la cuenta privada de una sola persona.

La capacidad DORA de control de versiones (se abre en una pestaña nueva) es concreta sobre lo que pertenece ahí: código de aplicación y dependencias, herramientas de creación de entornos, ficheros de composición de contenedores, configuración de nube y artefactos de IA como las peticiones.

Su base declarada es que «la investigación muestra de forma consistente que el uso completo del control de versiones predice la entrega continua».

Las orientaciones del GDS sobre control de versiones (se abre en una pestaña nueva) añaden la otra mitad de la regla, la revisión: «cada cambio de código lo revisa alguien que no lo escribió».

Juntos, esos hábitos son los que hacen posible un traspaso. Si recrear el sistema depende del portátil de alguien, no tienes un entregable: tienes una dependencia.

Planifica el calendario y el presupuesto

Un MVP enfocado suele planificarse en torno a una ventana de entrega de 6–8 semanas cuando el alcance encaja con esa forma. Es una referencia de planificación, no una promesa universal; integraciones, aprobaciones y sistemas heredados desconocidos pueden cambiar el calendario.

Ayuda saber cómo fallan los plazos del software, porque no fallan por igual en ambos sentidos.

Un estudio de 5.392 proyectos de TI publicado en el Journal of Management Information Systems (se abre en una pestaña nueva) halló que los sobrecostes siguen una ley de potencias en lugar de una distribución normal.

La mayoría de los sobrecostes son modestos, pero hay «una cola gruesa que incluye un número menor de proyectos con sobrecostes extremos». Planificar sobre la media subestima el riesgo que importa.

Y no es solo un problema de startups. La evaluación de alto riesgo de la TI federal del GAO (se abre en una pestaña nueva), publicada en enero de 2025, registra que las inversiones federales en TI «fracasan con demasiada frecuencia o incurren en sobrecostes y retrasos de calendario mientras contribuyen poco a los resultados relacionados con la misión».

Y eso con un gasto anual superior a 100.000 millones de dólares. La escala y el presupuesto no resuelven esto; la disciplina de alcance y los ciclos de retorno cortos sí.

Presupuesta decisiones, no solo horas de código. Descubrimiento, diseño, construcción, pruebas, despliegue, contenido, servicios de terceros y los arreglos posteriores al lanzamiento suman al esfuerzo de hacer útil la primera versión.

Un ejemplo trabajado

Piensa en un fundador que quiere una plataforma de reservas: los clientes reservan citas, los proveedores gestionan calendarios, ambas partes pagan y reciben recordatorios y un administrador lo supervisa todo. Es un producto real con una lista larga de funciones.

El flujo principal, sin embargo, es estrecho: un cliente encuentra un hueco libre y lo reserva, y el proveedor ve la reserva. Todo lo demás lo sostiene o puede esperar.

Una primera versión disciplinada podría ser así:

• En el alcance: disponibilidad del proveedor, reserva del cliente, una confirmación y una vista simple de próximas reservas para el proveedor.
• Aplazado: pagos en la aplicación (al principio, cobrar el depósito a mano), recordatorios automáticos, reseñas, búsqueda entre varios proveedores y el panel de administración.
• Decidido de antemano: qué datos de cliente se guardan y durante cuánto tiempo, de quién es el repositorio y qué significa «una reserva funcionó» como criterio de aceptación.

La lista aplazada no está abandonada: es la hoja de ruta. Pero publicar el núcleo primero responde a la única pregunta que importa pronto: ¿mantendrán los proveedores sus calendarios al día y reservarán los clientes?

Si lo harán, el resto merece construirse. Si no, ninguna integración de pagos lo habría salvado.

Para empezar

El objetivo no es predecirlo todo. El objetivo es hacer visibles los supuestos importantes, probar el flujo principal y crear una base de producto que pueda mejorarse sin tirar el trabajo.

Si tienes una idea pero no una especificación completa, empieza por el usuario, el flujo de trabajo y la decisión que necesitas que sostenga la primera versión. Esos tres puntos bastan para iniciar una conversación de planificación útil.