Cuánto cuesta la fase de discovery en 2026: qué pagar y qué no

La fase de discovery es un trabajo de pago, con alcance cerrado, que convierte un proyecto de software indefinido en uno con precio. Compras tres o seis semanas de atención de un equipo. Te devuelven un alcance, un plan técnico, un prototipo y una cifra lo bastante sólida para llevarla al presupuesto. En 2026 la tarifa de mercado va de 5.000 a 30.000 dólares en la mayoría de productos pequeños y medianos: en torno al 5-10% del coste del desarrollo que va a presupuestar.

El problema de quien compra es este. Un discovery real y una llamada comercial disfrazada producen los mismos artefactos: una cifra cerrada, unas semanas, un documento al final. La diferencia aparece cuatro meses después, cuando la estimación aguanta o se dobla. Así que la pregunta útil antes de firmar va más allá del precio medio: qué tiene que comprar ese dinero para que la cifra se sostenga.

¿Cuánto cuesta una fase de discovery en 2026?

Las tarifas que publican los estudios de desarrollo en 2026 se concentran en una franja estrecha, y la franja sigue al tamaño del proyecto más que al prestigio del estudio. Léelas como precios de mercado, no como un estándar: ningún organismo independiente los certifica.

• 5.000-12.000 dólares. Producto pequeño, concepto claro, pocas integraciones, un solo tipo de usuario. Dos o tres semanas.
• 12.000-30.000 dólares. Proyecto mid-market con varias integraciones, varios roles y permisos, migraciones de datos por resolver. Tres a seis semanas.
• Más de 40.000 dólares. Trabajo enterprise o regulado, donde el mapeo de compliance y la integración con el legacy se comen casi todo el calendario.

La regla del porcentaje afina más: el discovery suele valer entre el 5% y el 10% del desarrollo que presupuesta. Sobre un desarrollo de 180.000 dólares, un discovery de 12.000 es normal. Uno de 2.000 es una llamada comercial con factura. Uno de 60.000 significa que pagas tarifas de desarrollo por planificar, y que alguien ya ha empezado a construir.

Por qué el argumento "1 dólar ahora, 100 después" no se sostiene

Casi todos los estudios que venden discovery echan mano de la misma justificación: un defecto detectado en requisitos cuesta 1 dólar, el mismo defecto tras el lanzamiento cuesta 100. La curva se atribuye a Barry Boehm y lleva cuarenta años citándose.

Debajo hay poca evidencia. Las cifras originales vienen de material de formación interno de IBM, no de un estudio revisado por pares, y en 2001 el propio Boehm situó la proporción cerca de 5:1 para sistemas pequeños y no críticos. En 2017, Menzies y sus colegas contrastaron la tesis con 171 proyectos de software realizados entre 2006 y 2014, el estudio más amplio publicado sobre el efecto, y no encontraron rastro de él. Resolver un problema tarde no resultó ni sistemática ni sustancialmente más caro que resolverlo nada más aparecer. Su lectura: el efecto asoma de forma intermitente en ciertos proyectos y no debe tratarse como una ley del software.

Cuando un estudio te vende el discovery apoyándose en esa curva, el argumento va de folclore. El trabajo puede seguir mereciendo lo que pide. El razonamiento tiene que sostenerse en algo mejor que una cifra salida de un curso interno de 1981.

La razón real por la que el discovery vale su precio

Los requisitos están en el centro de los proyectos fallidos, y ahí los datos aguantan mejor que la curva de costes. El informe Pulse of the Profession del PMI sobre gestión de requisitos halló que el 47% de los proyectos fallidos incumple sus objetivos por una gestión imprecisa de los requisitos. La investigación CHAOS del Standish Group coloca los requisitos y especificaciones incompletos a la cabeza de los factores tras los proyectos en dificultades, con un 12,3%, y una definición clara de requisitos en tercer lugar entre los factores tras los que salen bien, con un 13,0%.

Fíjate en lo que describen esas cifras. La forma habitual de fracasar es construir lo que no toca con solvencia, a tiempo y según especificación. El discovery ataca justo eso. Obliga a tomar las decisiones que sobre papel cuestan una tarde y dentro de una base de código cuestan un trimestre: para quién es esto, qué sale primero, qué forma tiene el modelo de datos, qué queda fuera del alcance.

La segunda razón es comercial. Un proyecto indefinido no se puede presupuestar con honestidad. Un estudio que suelta un precio cerrado sobre un brief de dos páginas, o infla la cifra para cubrirse el riesgo, o cuenta con recuperar después vía peticiones de cambio. El discovery convierte las suposiciones en un alcance al que ambas partes pueden agarrarse. Compras una estimación fiable y la opción de marcharte con ella debajo del brazo.

Qué tiene que producir un discovery

El precio se juzga por los entregables, nunca por el calendario. Un discovery defendible entrega todo esto:

• Un alcance priorizado. Cada funcionalidad ordenada, con la línea del MVP marcada. Por escrito, no comentado en una llamada.
• Flujos de usuario y wireframes. Pantalla a pantalla, cómo se completa la tarea principal. En 2026 el estándar es un prototipo navegable en Figma.
• Un brief técnico. Stack, modelo de datos, plan de integraciones, autenticación, hosting. Con detalle suficiente para que otro equipo lo lea y arranque.
• Una estimación con rangos. Coste y plazo por hito, con la incertidumbre declarada punto por punto en vez de enterrada en un único porcentaje de contingencia.
• Supuestos y exclusiones. La lista que nadie escribe a gusto. Es la que evita la discusión del cuarto mes.
• Los riesgos, con nombre. Las tres cosas que con más probabilidad rompen la estimación, cada una con su impacto económico.

Si lo que te entregan es una presentación de conclusiones y una cifra en la última diapositiva, has pagado una propuesta. Las propuestas son gratis.

Cuándo el precio está mal

Dos direcciones, dos problemas distintos.

Demasiado barato. Por debajo del 3% del desarrollo, la cifra no cubre las horas que el trabajo exige. Alguien absorbe la diferencia como gasto comercial, y entonces el resultado sirve a la venta. Un discovery gratis o casi gratis es una oferta, y las ofertas se escriben para ganar, no para acertar.

Demasiado caro. Por encima del 15%, mira bien los entregables. Diseño de alta fidelidad de cada pantalla, un backend funcionando, ochenta páginas de documento de requisitos: son actividades de desarrollo con etiqueta de discovery. Comprarlas está bien. Lo que no cuadra es pagarlas como discovery cuando son desarrollo, y comprometerte antes de que exista la estimación.

Con la duración el control es más sencillo. Casi todos los discovery caben entre tres y seis semanas, y cuatro es la medida más común. Más allá, o el proyecto es complejo de verdad (regulado, legacy que integrar, muchos interlocutores), o el discovery se ha convertido en un proyecto aparte.

Qué no debes pagar

Dentro de un discovery de pago se cuela a menudo trabajo comercial que los estudios siempre han hecho gratis:

• Las primeras una o dos llamadas, horquilla de presupuesto aproximada incluida.
• La presentación de capacidades o el repaso de casos de éxito.
• La propuesta escrita del propio discovery.
• Una valoración a grandes rasgos de si tu proyecto encaja.

La línea es fácil de trazar. Si el artefacto solo te sirve a partir del momento en que contratas a ese estudio, es venta. Si conserva su valor cuando lo llevas a otro equipo, es trabajo, y el trabajo se paga.

Un ejemplo real: 12.000 dólares de discovery sobre un desarrollo de 180.000

Pongamos un SaaS B2B: multi-tenant, facturación con Stripe, un back office de administración, una integración con terceros. Desarrollo previsto en torno a 180.000 dólares, en línea con las cifras que vemos para ese alcance.

Un discovery de 12.000 dólares en cuatro semanas es proporcionado: el 6,7%. Por esa cifra: talleres con las personas que conocen el dominio de verdad, un backlog priorizado con la línea del MVP trazada encima, un prototipo navegable de los cuatro flujos principales, un brief técnico sobre el modelo de tenancy y la arquitectura de facturación, estimaciones por hito con rangos, y una lista de riesgos donde la integración con Stripe y la decisión de tenancy aparecen con nombre y con impacto económico.

Y ahora la prueba que importa. Pasa ese paquete a un segundo estudio y pídele que presupueste a partir de ahí. Si vuelve con una cifra cercana a la primera, el discovery cumplió: dejó el proyecto legible para cualquier equipo competente. Si te responde pidiendo hacer un discovery suyo, has comprado material de venta a tarifa de consultoría.

Esa prueba responde también a la pregunta del precio. El discovery merece lo que cuesta justo en el punto en que su resultado sobrevive al estudio que lo produjo.