MVP en 90 Días con Presupuesto Cerrado: qué es posible

La pregunta que escucho con más frecuencia de founders: "¿podemos tener algo en 90 días con €10.000?" La respuesta es casi siempre sí — con la condición de que sepas exactamente qué estás pidiendo.

El problema no es el plazo. El problema es la confusión entre lo que es un MVP, un prototipo y un producto completo. Esa confusión cuesta meses y dinero.

Qué es un MVP real (y qué no es)

MVP significa Minimum Viable Product: el producto más pequeño posible que permite validar una hipótesis de negocio con usuarios reales. No es una demo. No es un mockup clickable. No es un producto con "todas las features básicas".

Un MVP tiene tres características concretas: tiene un flujo completo que funciona de extremo a extremo, permite a usuarios reales realizar la acción central del negocio, y genera datos suficientes para decidir si la dirección es correcta.

Lo que no es un MVP:

• Un prototipo en Figma (eso es diseño, no producto)
• Una landing page con formulario de interés (eso es validación de demanda, no MVP)
• Un producto con el 80% de las features que quieres lanzar "cuando esté completo"

Qué puede construirse en 90 días con €5k–15k

La respuesta depende completamente del tipo de producto. Pero como referencia práctica, en 90 días con presupuesto entre €5.000 y €15.000 puede construirse:

La clave es que el presupuesto y el plazo son fijos, lo que varía es el alcance. Un desarrollo de software a precio fijo funciona exactamente así: el proveedor y el cliente definen juntos qué entra en el MVP antes de que empiece el desarrollo.

Por qué fallan la mayoría de los MVPs

He visto MVPs fallidos desde los dos lados: como CTO que tuvo que rescatarlos y como asesor de founders que habían gastado su presupuesto sin tener nada funcional. Las causas se repiten.

Scope creep sin control

El alcance inicial parecía razonable. Pero durante el desarrollo, el cliente fue añadiendo "pequeñas" funcionalidades que no estaban en el plan original. Cada una parecía trivial. En conjunto, duplicaron el tiempo de desarrollo. El MVP llega tarde, con el presupuesto agotado y sin haber validado nada.

Sin validación previa del problema

El error más caro: construir un MVP para un problema que no existe o que los usuarios no están dispuestos a pagar por resolver. Antes de escribir una línea de código hay que tener evidencia real de que el problema existe, que hay personas que lo sufren y que están dispuestas a pagar por la solución.

Perfeccionismo disfrazado de criterio técnico

Hay equipos que no lanzan porque "falta poco para que esté bien". En 17 años he aprendido que ese "poco" nunca llega. Un MVP es suficientemente bueno cuando permite aprender, no cuando está perfecto.

Cómo el Framework 3R cambia el resultado

El Framework 3R — Fricción, Regla, Retorno — es el método con el que trabajamos en BeC para definir el alcance de un MVP antes de empezar a construir.

Fricción: ¿cuál es el problema real que sufre el usuario? No el problema que creemos que tiene — el que podemos verificar con datos o conversaciones directas. La fricción mal definida lleva a soluciones que nadie usa.

Regla: ¿qué restricciones existen? Presupuesto, plazo, capacidad del equipo, requisitos legales, integraciones obligatorias. Las reglas del proyecto determinan qué puede hacerse en el tiempo disponible. Ignorarlas produce planes que no se cumplen.

Retorno: ¿qué tiene que ocurrir para que el MVP sea un éxito? Definir el criterio de éxito antes de empezar a construir cambia cómo se prioriza el alcance. Un MVP que no tiene definido qué significa "validado" no puede fallar — y tampoco puede tener éxito.

El resultado de aplicar el Framework 3R antes de empezar es un alcance concreto, justificado y realista. No perfecto — realista. Y eso es lo que permite entregar en 90 días sin sorpresas.

Si el MVP tiene sentido después de esa sesión, podemos formalizarlo como proyecto de desarrollo de software a precio fijo con entrega en 90 días. Si no tiene sentido — si el problema no está suficientemente validado o el alcance no encaja en el presupuesto — también te lo decimos. Prefiero eso a que pierdas tiempo y dinero en algo que no va a funcionar.

Para proyectos en etapa muy temprana, también existe la opción de consultoría para startups, que incluye validación de la hipótesis de producto antes de decidir si tiene sentido construir el MVP.