Flyvbjerg y Budzier analizaron 1.471 proyectos de tecnología y encontraron un sobrecoste medio del 27%. El dato que importa es otro: uno de cada seis se desvió un 200% de media en coste y casi un 70% en plazo. La media engaña, la cola mata. Y la discusión de precio cerrado vs bolsa de horas en software va, en el fondo, de quién se come esa cola cuando te toca.
En Docastix cerramos presupuesto en la mayoría de nuestros proyectos de desarrollo de apps móviles. La letra pequeña es lo que quizá no esperas: cerramos precio después del discovery, nunca antes, y hay proyectos a los que les decimos que cerrar precio es mala idea.
Respuesta rápida: precio cerrado vs bolsa de horas, cuál te conviene
El precio cerrado no es un modelo de contratación: es la consecuencia de haber hecho un discovery serio. Con alcance escrito, prototipado y con criterios de aceptación, cerrar precio es razonable. Sin eso es una apuesta que paga alguien: tú en recortes y peleas por cada cambio, o el equipo comiéndose horas. Y no son dos modelos, son tres.
| Modelo | Quién asume el riesgo | Encaja cuando | Es una trampa cuando |
|---|---|---|---|
| Precio cerrado | El proveedor | Alcance escrito y fecha dura | El alcance está por descubrir |
| Bolsa de horas | El cliente | Trabajo impredecible o volumen bajo | No hay tope ni reporte detallado |
| Capacity / equipo por sprint | Compartido | El producto está vivo y se decide sobre la marcha | Nadie prioriza del lado del cliente |
Quédate con tres ideas: el discovery hace posible el precio cerrado, una bolsa de horas sin tope no es un contrato y el mejor reparto de riesgo es una secuencia de los tres.
El precio cerrado es la consecuencia de un discovery, no un favor comercial
Cuando pides «un precio cerrado» lo que pides es certidumbre, y esa no la produce el contrato: la produce el trabajo previo. Un número cerrado solo sale de un alcance cerrado.
De ahí una consecuencia incómoda: quien te cierra precio sobre media página hace una de tres cosas. O mete un colchón tan gordo que pagas por incertidumbre que quizá nunca llegue. O ha calculado con optimismo y recuperará margen discutiendo cada cambio. O entregará menos de lo que crees haber comprado.
No es mala suerte estadística: en el análisis de 1.355 proyectos públicos de tecnología de Budzier y Flyvbjerg, el proyecto típico duraba un 24% más de lo previsto y cada año adicional sumaba 4,2 puntos porcentuales de riesgo de coste. Cuanto más largo y difuso es lo que firmas, más caro es el seguro que alguien paga.
Que cerramos precio tras el discovery ya está publicado en la guía de cuánto cuesta desarrollar un SaaS: el precio que firmas es el que pagas y el código es 100% tuyo desde el primer commit. Lo sostenemos porque el orden es ese, no al revés.
Los tres modelos que existen de verdad
Para cada uno importan tres cosas: quién asume el riesgo, qué incentivo crea en ambas partes y en qué situación deja de funcionar.
Precio cerrado
Firmas un alcance y un importe, y el proveedor asume el riesgo de estimación. El incentivo es terminar dentro de lo estimado: sano con el alcance definido, tóxico sin él, porque empuja a discutir si algo «entraba o no entraba» y a resolver por lo barato. En ti crea el contrario: meter todo lo imaginable en la definición por si acaso, y eso sube el precio antes de empezar.
Encaja con alcance escrito y prototipado, fecha dura por un motivo real —una feria, una normativa, una ronda— y poca ambigüedad en las integraciones. El caso canónico es un producto mínimo viable bien delimitado.
Sus límites, sin adornos: es rígido ante cambios por diseño, pagas un colchón por incertidumbre que puede no llegar nunca, y es mala pareja para producto en descubrimiento, donde lo aprendido en la semana tres solo genera un anexo.
Bolsa de horas (time & materials)
Compras horas y se consumen contra trabajo real, así que el riesgo de estimación lo asumes tú. Ganas flexibilidad total y pierdes el incentivo del proveedor para ir rápido, porque cobra por hora trabajada. No es mala fe: la disciplina la pones tú con reporte, prioridades y tope.
Encaja en trabajo impredecible —correctivo, incidencias, adaptaciones normativas, integraciones sin documentar— y cuando el volumen es tan bajo que montar un contrato cerrado cuesta más que el trabajo. Los tramos del mantenimiento están en cuánto cuesta mantener una app.
Es una trampa sin tope de gasto, con un parte que dice «desarrollo, 80 h» y sin nadie revisando el consumo hasta que se ha ido el 70% del presupuesto: un grifo abierto con tu nombre en la factura.
Capacity o equipo dedicado por sprint
Contratas capacidad estable —dos personas, tres, un equipo— durante un número de sprints. No compras funcionalidades ni horas sueltas: compras semanas de un equipo que ya conoce tu producto. Es el único de los tres donde nadie gana discutiendo el alcance, porque se decide cada dos semanas.
Encaja en producto vivo, con roadmap que se reordena según datos de uso. Es el modelo natural después de una v1 y el que usamos cuando un cliente de desarrollo SaaS entra en evolución continua.
Es una trampa cuando de tu lado nadie prioriza: un equipo dedicado sin dueño de producto quema semanas construyendo lo que alguien pidió por correo el martes. Y cuando el alcance ya estaba definido, porque pagas una flexibilidad que no necesitas.
La tabla de decisión
Mandan dos variables: cuánto sabes de tu alcance y quién manda técnicamente de tu lado. La segunda se ignora casi siempre y pesa igual.
| Tu situación | Sin perfil técnico interno | Con producto o CTO interno |
|---|---|---|
| Alcance claro y fecha dura | Precio cerrado, sin dudarlo | Precio cerrado, y tú controlas los criterios de aceptación |
| Producto en descubrimiento | Discovery cerrado y después capacity acompañado | Capacity desde el principio |
| Mantenimiento y trabajo impredecible | Bolsa de horas con tope y reporte detallado | Bolsa de horas o cuota fija, según volumen |
| No sabes en cuál estás | Discovery a precio cerrado y decides al terminar | Discovery corto, casi siempre interno |
Sin perfil técnico en casa, el precio cerrado te protege más de lo que te limita: traslada un riesgo que no puedes evaluar. Con un CTO que prioriza cada dos semanas, te ata las manos a cambio de una certeza que ya no necesitas.
El discovery es la bisagra: qué hace falta para cerrar precio de verdad
Un discovery no es una reunión larga: es una fase con cuatro entregables.
- Alcance escrito, con lo que queda fuera igual de escrito. La lista de «no entra en la v1» evita casi todas las discusiones posteriores.
- Prototipo navegable. Ahí se cae la pantalla que a ti te parecía obvia y nadie entiende, y aparecen los estados que faltaban.
- Integraciones identificadas. Qué API, qué versión, qué límites, quién tiene las credenciales. Una que «existe» y otra con documentación y entorno de pruebas son dos costes distintos.
- Criterios de aceptación. Sin ellos, «terminado» es una opinión, y las opiniones no se cierran en un precio.
En un proyecto medio en España, del orden de 40.000 €, pesa entre el 5% y el 10% del presupuesto: de 2.000 a 4.000 €. A tarifas senior de 65-110 €/h son entre 20 y 60 horas de producto, diseño y arquitectura. En un MVP de 8.000 € se comprime a unos días; en un proyecto complejo es una fase de semanas.
Haz la cuenta al revés: pagar 3.000 € por saber qué vas a construir antes de comprometer 40.000 € sale barato incluso si decides no seguir. Es el motivo por el que un presupuesto real de una app desglosado por fases resulta creíble y uno de tres líneas no. Además, el discovery es la única fase donde los cambios son gratis: mover una pantalla en un prototipo cuesta minutos; con backend, pruebas y una release en revisión cuesta días.
Cómo se manipula cada modelo, con nombre y apellidos
Precio bajo para ganar el concurso. Se entra por debajo del mercado sabiendo que el margen se recupera en los cambios. La señal es un precio fuera de los rangos publicados —los tienes en cuánto cuesta hacer una app— sin explicación. Pregunta qué han quitado para llegar ahí; si contestan «somos más eficientes», sigue preguntando.
Alcance ambiguo redactado a propósito. Verbos elásticos —«gestión de usuarios», «panel de administración», «integración con tu ERP»— que caben en 20 horas o en 200 según convenga. La señal es una propuesta sin lista de pantallas y sin exclusiones. Pide un criterio verificable al lado de cada línea: quien no quiera escribirlo te dice algo.
Horas que no se justifican. Un parte que dice «desarrollo: 96 h» no es un reporte, es una cifra. Exige detalle por día, persona y tarea, con enlace al ticket correspondiente.
Junior facturado como senior. El más difícil de detectar y el más caro. Contramedida doble: tarifa por perfil en el contrato —25-40 €/h junior, 40-65 €/h mid, 65-110 €/h senior en España— y saber quién ha tocado tu código, visible en el historial del repositorio si el repositorio es tuyo. Si te niegan ese acceso, ya tienes la respuesta.
Equipo fantasma en capacity. Contratas dos personas a dedicación completa y en la práctica son cuatro al 50% saltando entre clientes. Pide nombres, dedicación y que quienes salen en la propuesta estén en la demo.
Que esto no es paranoia lo dice el sector: la investigación recopilada en el PM World Journal en enero de 2026 sitúa el éxito completo de los proyectos IT en el 31% para 2020-2024, con un 50% con retrasos o sobrecostes y un 19% cancelados. Y el scope creep va a más: el PMI documentó un 52% de proyectos con cambios de alcance no controlados frente al 43% de cinco años antes.
Qué tiene que decir el contrato en cada caso
Comunes a los tres modelos:
- Defecto frente a cambio. Defecto: no hace lo que dice la especificación. Cambio: ahora quieres que haga otra cosa. Esa frase resuelve casi todas las discusiones antes de que existan. Añade garantía de corrección sin coste y tiempos de respuesta por severidad.
- Procedimiento de cambios con precio acordado antes de ejecutar. Petición por escrito, estimación en horas y euros, impacto en el plazo, aprobación explícita, y solo entonces se toca el código. Sin ese orden, los cambios aparecen en la factura.
- Propiedad del código desde el primer commit. Cesión en exclusiva de los derechos de explotación, repositorio en una organización tuya con el equipo invitado como colaborador y no al revés, cuentas de Apple y Google a tu nombre y lista de librerías de terceros con su licencia.
- Condiciones de salida. Preaviso, código documentado, despliegue reproducible, credenciales y horas de acompañamiento al equipo entrante. Si el proyecto es crítico y el código no vive en tu infraestructura, entra además un acuerdo de escrow, que merece artículo propio. Escríbelo cuando la relación va bien.
Propias del precio cerrado. Alcance como anexo numerado y versionado, con exclusiones. Hitos de pago ligados a entregables que puedas abrir y probar, no a fechas. Criterios de aceptación por hito.
Propias de la bolsa de horas. Reporte con fecha, persona, perfil y tarea. Tarifa por perfil, no una única promediada. Tope de gasto con aviso obligatorio al alcanzar un porcentaje pactado —el 70% u 80% funciona bien— y qué pasa con las horas no consumidas.
Propias del capacity. Composición nominal del equipo y dedicación, duración mínima y preaviso de baja, demo en entorno real al final de cada sprint, y quién prioriza de tu lado con nombre: tu obligación contractual aquí.
El mapa completo de a quién contratar está en cómo elegir el mejor equipo para desarrollar tu app.
El híbrido que suele funcionar
La secuencia que mejor reparte el riesgo no es un modelo, son tres encadenados.
- Discovery a precio cerrado y pequeño. Dos a cuatro semanas, importe acotado, entregables definidos y compromiso económico bajo para los dos lados.
- V1 a precio cerrado sobre ese alcance. Ahora sí hay algo que cerrar: el proveedor asume el riesgo de estimación con información suficiente y tú compras certidumbre sobre lo que ya has visto en pantalla. El plazo típico está en cómo sacar un MVP en menos de 3 meses.
- Evolutivo por capacity o bolsa de horas. En producción el alcance deja de ser cerrable: los usuarios empiezan a opinar.
Funciona porque cada tramo asigna el riesgo a quien mejor puede controlarlo: en el discovery es de conocimiento y se reduce trabajando; en la v1 es de estimación y lo asume quien estima; en el evolutivo es de priorización y lo asumes tú. Asignar riesgo a quien no lo controla acaba mal.
Saltarse el paso 1 para «ir más rápido» es lo que produce los sobrecostes del principio. El PMI, en su Pulse of the Profession de 2026, cifra en un 31% los proyectos complejos que no alcanzan todos los beneficios esperados, y señala los requisitos que cambian a mitad de camino como factor recurrente.
Qué preguntar en la primera llamada
Precio cerrado sin discovery previo: ¿sobre qué documento has calculado el número? ¿Qué pasa si la integración con mi ERP resulta el doble de trabajo? ¿Me enseñas lo que no entra?
Bolsa de horas: ¿cómo es el reporte y me lo puedes enseñar anonimizado? ¿Qué tarifa tiene cada perfil? ¿Hay tope y a qué porcentaje avisáis? ¿Caducan las horas?
Capacity: ¿quiénes componen el equipo, con nombre y dedicación? ¿Cuántos clientes lleva cada uno en paralelo? ¿Quién esperáis que priorice de mi lado?
En los tres casos: ¿de quién es el código y desde cuándo? ¿Qué es un defecto y qué un cambio, por escrito? ¿Cómo salimos si esto no funciona? Si prefieres una horquilla antes de la llamada, nuestra calculadora de presupuesto te da un rango en minutos.
Conclusión
La pregunta «precio cerrado o bolsa de horas» está mal planteada: asume que es una decisión de contrato cuando es una decisión sobre cuánto sabes. Con alcance definido y fecha dura, el precio cerrado es la respuesta correcta. Con producto en descubrimiento, es comprar rigidez y pagar un colchón por incertidumbre que quizá no aparezca. Con trabajo impredecible, la bolsa de horas es lo honesto, con tope y reporte detallado.
Nosotros cerramos precio, y por eso insistimos tanto en el discovery: sin él, ese compromiso sería una apuesta disfrazada de garantía. Si tienes un presupuesto encima de la mesa y no sabes en cuál de los tres modelos estás, escríbenos en contacto y te decimos con cuál lo plantearíamos; si tu caso es de bolsa de horas, te lo diremos igual aunque nos convenga lo contrario.
Preguntas frecuentes
Depende de cuánto esté definido el alcance. Con alcance escrito, prototipo y criterios de aceptación gana el precio cerrado, porque traslada el riesgo de estimación al proveedor. Con trabajo impredecible o un producto en descubrimiento encajan mejor la bolsa de horas o un equipo por sprint.