¿Cuánto cuesta y cuánto tarda un MVP? La guía honesta

"Depende" es honesto pero inútil

La pregunta más frecuente en nuestras primeras reuniones con clientes es siempre variación de la misma: "¿cuánto costaría hacer esto?". La respuesta más honesta es, efectivamente, que depende. Depende de las integraciones necesarias, de la complejidad del modelo de datos, del nivel de regulación del sector, de si hay diseño previo o hay que partir de cero, de los compromisos de SLA que el producto necesite ofrecer.

Pero "depende" sin más explicación es inútil. Si alguien llega con una idea de SaaS y le dices que puede costar entre 20.000 y 500.000 euros, no le has ayudado a decidir nada. Llevamos años estimando proyectos y podemos ser más precisos, siempre que la persona que pregunta entienda qué variables mueven el número y esté dispuesta a concretar algunas.

Lo que sigue es el marco que usamos internamente para hacer estimaciones de MVP antes de tener una spec completa. No reemplaza a una fase de discovery detallada, pero sirve para dar una primera orientación de orden de magnitud. Y, en casi todos los casos, ese orden de magnitud es lo que el cliente necesita para decidir si invertir tiempo en una conversación más profunda.

Las variables con mayor peso

Integraciones con sistemas externos

Este es el factor que más subestiman los clientes y más subestiman muchos proveedores. Cada integración con un sistema externo tiene costes de análisis, desarrollo, testing y mantenimiento que no son proporcionales a lo que parece desde fuera.

Una integración con un ERP tipo SAP, con un CRM tipo Salesforce, con un sistema hospitalario en HL7, o con una pasarela bancaria en PSD2, puede agregar entre dos y cuatro semanas de trabajo de ingeniería por integración —independientemente de si "debería ser simple". Las APIs externas tienen documentación incompleta, comportamientos no documentados, limitaciones que solo aparecen en la semana tres, y entornos de sandbox que difieren de producción de formas sutiles. En un MVP con cuatro integraciones, el coste de las integraciones puede ser mayor que el del producto en sí.

Una regla que aplicamos: cada integración externa descrita como "simple" en la fase comercial debería presupuestarse como "moderada" en la fase técnica. La razón es estadística: las integraciones que fueron realmente simples son minoría, y el coste asimétrico de equivocarse en la dirección contraria es alto.

Complejidad del modelo de datos

Un SaaS con usuarios, proyectos y tareas es fundamentalmente diferente de un SaaS con estructuras jerárquicas profundas, múltiples relaciones many-to-many con atributos, versionado de entidades, e historial auditable de cambios. La complejidad del modelo de datos afecta no solo al desarrollo inicial sino a la velocidad de todo lo que viene después: cada feature nueva se apoya en ese modelo, y un modelo mal diseñado ralentiza todo lo demás.

Un modelo mal diseñado no se refactoriza, se reescribe. Por eso invertimos tiempo desproporcionado en la fase de diseño del modelo en discovery: es la única inversión que devuelve durante toda la vida del producto.

Autenticación y gestión de accesos

Si el producto es B2B con roles múltiples dentro de una organización, SSO corporativo, y políticas de acceso configurables por cliente, la autenticación deja de ser un componente resuelto. Si además entran requisitos de auditoría (quién vio qué y cuándo), el coste escala.

La decisión de usar un proveedor gestionado (Auth0, Cognito, Keycloak) desde el día uno ahorra mucho tiempo frente a construir auth propia, pero sigue habiendo trabajo no trivial de configuración, integración de roles específicos del producto, y flujos de invitación y onboarding.

Requisitos regulatorios

Si el producto opera en salud, finanzas, educación reglada o cualquier sector con regulación específica, añade entre un 30% y un 50% al presupuesto. No es margen: es trabajo real de análisis de cumplimiento, implementación de controles técnicos, documentación y, en el caso de productos sanitarios, posible certificación. Este coste no desaparece si lo ignoras; aparece más tarde, normalmente en el peor momento.

Las variables con más peso en un presupuesto de MVP raramente son las más visibles desde fuera.

Rangos por tipo de producto

Con esas variables en mente, estos son los rangos en los que nos movemos habitualmente.

SaaS CRUD básico. Producto con autenticación de usuarios, modelo de datos relativamente plano, sin integraciones externas relevantes y sin requisitos regulatorios especiales. Cobertura de funcionalidad core sin analytics avanzados ni configurabilidad compleja. Rango habitual: 8 a 12 semanas, 25.000 a 40.000 euros.

SaaS con integraciones significativas. Mismo punto de partida pero con dos o más integraciones con sistemas externos, modelo de datos más complejo, o requisitos específicos de reporting. Rango habitual: 14 a 20 semanas, 50.000 a 85.000 euros.

Software en sectores regulados. Salud, finanzas, educación reglada. El cumplimiento normativo, la documentación técnica y los controles de seguridad se suman al desarrollo. Añade un 30-50% a cualquiera de las categorías anteriores.

Plataforma con IA integrada. Si el MVP incluye componentes de ML o LLMs más allá de llamadas directas a APIs, el coste de infraestructura de datos, experimentación y validación del comportamiento del modelo añade tiempo y presupuesto difíciles de predecir sin análisis más detallado. Nuestra recomendación: separar el componente IA en una fase de exploración de 4 a 6 semanas antes de comprometer presupuesto de MVP completo.

Trampas de scope específicas

Estas son las subestimaciones más frecuentes que vemos.

El panel de administración "simple". Casi todos los proyectos necesitan un backoffice para gestión de usuarios, configuración de parámetros, soporte operativo, impersonación para debugging. Ese panel casi siempre acaba siendo más complejo de lo previsto porque reúne toda la complejidad del negocio en una interfaz. Planificarlo explícitamente desde el principio evita que aparezca como sorpresa en la semana diez.

El sistema de notificaciones. Email transaccional, push notifications, in-app alerts, y especialmente la lógica de qué se notifica a quién y cuándo, es un módulo que se subestima sistemáticamente. Las notificaciones tienen que funcionar de forma fiable (los emails de reset de contraseña no pueden perderse), la lógica de negocio que las activa puede ser tan compleja como el producto principal, y la configurabilidad por usuario —poder silenciar ciertos tipos, agrupar, preferir canal— añade mucho trabajo no visible.

Multitenancy desde el primer día. Si el producto es un SaaS B2B, la separación de datos entre clientes tiene que estar en el diseño inicial. Añadirla después es refactor profundo. Pero implementarla correctamente desde el inicio tiene un coste que hay que contemplar.

Export, importación y migración de datos. Los clientes enterprise lo piden siempre, aunque no aparezca en la primera spec. "Exportar a CSV" suena simple hasta que el modelo de datos tiene relaciones y los formatos de exportación tienen que ser utilizables downstream.

El coste de no hacer discovery: un caso real

El error más caro que hemos visto no es la sobreingeniería ni el stack equivocado: es empezar a construir antes de entender bien el problema.

Hace unos años entramos en un proyecto donde un cliente había gastado seis meses con otro proveedor en una plataforma que, cuando la probaron con usuarios reales, no resolvía el problema correcto. La spec original asumía un flujo de trabajo lineal. La realidad de los usuarios era ramificada, con múltiples puntos de decisión y estados. Reconstruir la plataforma sobre el modelo correcto requirió casi tanto tiempo como construirla la primera vez.

En otro proyecto, menos dramático pero igual de ilustrativo, dos semanas de discovery revelaron que el módulo de configuración avanzada que el cliente había especificado como crítico iba a ser usado por menos del 5% de los usuarios. Lo que el 95% necesitaba era un flujo guiado mucho más simple. Construir el flujo simple tomó dos semanas; el módulo avanzado habría tomado dos meses. La fase de discovery, que costó unos 8.000 euros, ahorró alrededor de 60.000 en desarrollo y un producto peor.

Una fase de discovery de dos a cuatro semanas cuesta entre 5.000 y 12.000 euros dependiendo de la complejidad del dominio. Ese gasto previo al desarrollo ahorra, en los casos donde el problema no estaba bien entendido, meses de trabajo en dirección incorrecta. No es opcional si el problema tiene complejidad real de negocio.

Dos semanas de discovery pueden ahorrar seis meses de desarrollo en la dirección equivocada.

Por qué la velocidad cae después de la semana seis

Un patrón que observamos en casi todos los proyectos de cierta complejidad: la velocidad percibida del equipo es alta las primeras cuatro o cinco semanas y después cae. No es un síntoma de mal equipo: es inherente a la forma en que el software se construye.

Las primeras semanas el trabajo es de scaffolding. Se arma la arquitectura, se implementan los primeros CRUDs, todo lo que se construye es código nuevo sin deuda técnica. A partir de la semana seis, cada feature nueva requiere integración con lo anterior. Las integraciones externas que parecían cerradas en el análisis empiezan a mostrar comportamientos no documentados. Los edge cases que no aparecían en los flujos principales empiezan a acumularse. La deuda técnica razonable del inicio empieza a cobrar intereses.

Un buen equipo anticipa esto: deja refactorings pequeños programados a lo largo del proyecto, no los pospone a una fase final que nunca llega. Un cliente consciente entiende esto: la semana 12 de un proyecto produce menos features que la semana 4, pero las que produce son más robustas. Comparar velocidad en semanas distintas sin ese contexto genera expectativas irreales y presión que empeora el producto.

Cómo obtener una estimación concreta de un proveedor

Si quieres que un proveedor te dé un presupuesto fiable, prepara cinco cosas antes de la primera llamada.

1. Una descripción del problema de negocio, no de la solución. "Queremos reducir el tiempo de onboarding de clientes nuevos" en vez de "queremos construir un wizard de cinco pasos".
2. Una caracterización de los usuarios y del flujo principal: quiénes son, qué hacen hoy, qué necesitan hacer con el producto.
3. Una lista de sistemas externos con los que tiene que integrar, con indicación del nivel de profundidad (lectura, escritura, tiempo real).
4. Los requisitos regulatorios conocidos y los que sospechas que pueden aplicar.
5. Un rango de presupuesto orientativo que estás dispuesto a invertir y el horizonte temporal en el que esperas resultados.

Con esa información, un proveedor serio puede darte una estimación con margen de ±20% antes de firmar. Sin ella, solo puede darte rangos amplios —los mismos que aparecen en este artículo—, que no son especialmente útiles para decidir. Y si un proveedor te da un número preciso sin haberte pedido nada parecido a esta información, probablemente ese número no sobrevivirá al contacto con la realidad del proyecto.