Precio cerrado o por horas: cómo elegir el contrato
El precio cerrado funciona cuando lo que pediste ya está decidido y poco va a cambiar. El pago por horas funciona cuando una parte del pedido todavía hay que descubrirla. El contrato define quién carga con la incertidumbre: en el precio cerrado es el proveedor, que la mete en la cifra. Por horas, eres tú, que pagas lo que cueste el descubrimiento.
¿Precio cerrado o por horas: qué contrato conviene?
Elige según cuánto del pedido está asentado. Si puedes decir qué entra, qué sale, quién lo usa y qué sistemas y hojas de cálculo toca el sistema nuevo, y casi nada de eso va a cambiar, el precio cerrado es coherente. Si una parte depende de descubrir cómo funciona de verdad la operación, por ejemplo una regla de precios que solo existe en la cabeza de una persona, el formato por horas, mejor con tope, se ajusta a lo que realmente sabes.
Hay una prueba sencilla. Pregúntate: si cambio de idea en la sexta semana, ¿quién paga? En el precio cerrado, el cambio se vuelve adenda y negociación. Por horas, se vuelve horas en la factura del mes. Ninguno de los dos formatos elimina el cambio. Cada uno decide quién lo absorbe.
¿Qué dice la investigación sobre los contratos de desarrollo de software?
Que el formato es una decisión sobre riesgo y confianza, y que ningún estudio señala un ganador. Los tres trabajos siguientes son anteriores a 2025, pero son lo que la literatura académica ofrece en medición directa sobre este tema.
Patrick Bajari y Steven Tadelis publicaron en 2001, en el RAND Journal of Economics, un modelo en el que el comprador intercambia incentivos por costes de renegociación. Muestran que el contrato por coste es preferible al precio cerrado cuando el proyecto es más complejo. La lógica es que, en un proyecto complejo, el diseño cambia después de la firma, y renegociar un precio cerrado tiene un coste propio.
El dato empírico más útil es de Lior Fink, Yossi Lichtenstein y Simon Wyss, publicado en 2013 en Applied Economics. Analizaron 270 contratos de desarrollo de software firmados entre enero de 2000 y abril de 2003 por un banco internacional, con unos 100 proveedores. Hubo 139 contratos de precio cerrado estándar (51%), 42 de precio cerrado rígido (16%), 43 por horas puro (16%), 14 por horas con tope (5%) y 32 mixtos (12%). Los mixtos tenían un precio medio de 632 mil dólares, frente a 284 mil del precio cerrado estándar. Según los autores, un precio mayor, que usan como indicador de incertidumbre, aparece junto a contratos menos completos.
Este estudio mide el tipo de contrato, no el resultado del proyecto. Viene de un único banco. Sirve para mostrar que, incluso en un comprador grande donde dos tercios de los contratos eran a precio cerrado, el 17% usó formatos mixtos o por horas con tope, y los mixtos costaban de media más del doble que el precio cerrado estándar.
El tercer trabajo es de Yossi Lichtenstein y Alan McDonnell, presentado en 2003 en la Conferencia Europea de Sistemas de Información (ECIS). La hipótesis era que los proyectos arriesgados se contratarían por horas y los demás a precio cerrado. En 14 proyectos externos de dos grandes empresas, los datos no la sostuvieron. En las entrevistas con directivos, una de las empresas contrataba los proyectos arriesgados a precio cerrado y pagaba una prima de riesgo para no tener que volver a presupuestar. La otra solo aceptaba el precio cerrado con proveedores de confianza.
Lo que se desprende: el criterio no es el formato. Es quién acepta cargar con qué, y con cuánta confianza.
¿Por qué el precio cerrado sale caro cuando el pedido es vago?
Porque los sobrecostes en software son raros pero enormes, y alguien tiene que pagarlos.
Bent Flyvbjerg y colegas compararon 23 tipos de proyecto en un estudio del volumen 57 (2026) del Project Management Journal, con 11.011 proyectos. De los 5.360 proyectos de TI de la muestra, el 40,86% superó el presupuesto. En el 18,26% el sobrecoste pasó del 50%, y en esos casos el coste final medio fue 5,53 veces la estimación. Los autores concluyen que TI es el único tipo cuya cola de sobrecostes es tan pesada que el riesgo se vuelve impredecible, y proponen como explicaciones el carácter a medida del software y las decisiones tomadas demasiado rápido. Como remedio sugieren modularidad y decidir con más calma.
La conexión con el contrato es lectura nuestra, no un resultado del estudio. Un proveedor que conoce esa cola tiende a poner una reserva en el precio cerrado cuando el pedido es vago, y tú pagas esa reserva aunque el proyecto vaya bien. Cuando el pedido está bien descrito, la reserva se reduce, porque lo que el proveedor no sabe se reduce. El coste del precio cerrado depende, entonces, menos de la negociación y más de cuánto lograste decidir antes de pedir.
Por eso el problema rara vez es el contrato. No tienes un problema de precio cerrado o por horas. Tienes un problema de arquitectura: el pedido todavía no sabe qué es.
¿Cómo repartir la incertidumbre en vez de elegir bando?
Separando el pedido en dos pilas y dando a cada una el contrato que le corresponde.
En la primera pila van las partes decididas: pantallas, flujos y reglas que alguien puede describir y validar. Esas encajan con el precio cerrado, mejor divididas en módulos pequeños, con entregas intermedias. En el estudio de Fink y colegas, más entregas intermedias aparecen junto a contratos más completos, lo que tiene sentido: cada entrega es una fecha en la que ambas partes comprueban lo acordado.
En la segunda pila van las partes por descubrir: la regla que solo conoce un empleado, la integración con un sistema que nadie documentó. Esas encajan con una fase corta de descubrimiento a precio cerrado, cuyo entregable es un documento de reglas y un mapa de integraciones. Lo que el descubrimiento documenta pasa a la primera pila. Lo que siga siendo incierto después va por horas con tope, y el tope es lo que evita que el pago por horas se convierta en un cheque en blanco.
Hay un paso previo que reduce la segunda pila por sí solo. Ejecutar el proceso a mano durante tres semanas antes de firmar convierte parte de la incertidumbre en registro, y el registro se vuelve especificación. Cuanto más se parece el pedido a una especificación, más justo es el precio cerrado para ambas partes.
Falta una regla escrita para los cambios de alcance: quién puede pedirlos, quién los aprueba, cómo se informa el impacto en plazo y coste antes de ejecutar. Sin ella, los dos formatos producen la misma discusión, solo que en momentos distintos.
¿Cómo se ve esto en una operación real?
Considera un escenario hipotético: una distribuidora mediana quiere un portal de pedidos para sustituir la hoja de cálculo y los chats del equipo comercial. Dos cosas están decididas: el registro de clientes y el flujo del pedido, del envío a la aprobación. Dos no: la regla de precios por cliente, que hoy vive en la cabeza del gerente comercial, y la integración con el control de existencias, que se lleva en una hoja de cálculo.
Una propuesta única a precio cerrado obliga al proveedor a adivinar las dos incertidumbres y a ponerles precio. Un reparto más claro tendría tres bloques. Primero, de dos a tres semanas de descubrimiento a precio cerrado, con entrega de reglas de precios documentadas y un mapa de integración con las existencias. Segundo, el módulo de registro y pedidos a precio cerrado, ya con lo que reveló el descubrimiento. Tercero, la regla de precios y la integración: a precio cerrado, si el descubrimiento logró documentarlas, o por horas con tope y revisión en cada entrega, si la hoja de existencias todavía guarda reglas que nadie sabe describir.
Los plazos anteriores son ilustración, no medición. Lo importante es la estructura: la incertidumbre aparece pronto, en un bloque corto y barato, en lugar de aparecer en la semana ocho dentro de un precio que ya se pagó.
Los casos de Yowpi muestran una secuencia cercana, aunque no registran el formato de contrato usado. Colo Saúde empezó con un rescate acotado, una auditoría de seguridad y un ajuste de rendimiento, que llevó la seguridad de 7/10 a 10/10 en la auditoría de la propia Yowpi y redujo un 60% el consumo de unidades de procesamiento de Bubble (WUs). Los proyectos siguientes llegaron después, con la confianza establecida. UniTrust empezó con un sistema en producción en dos semanas, en agosto de 2022, y la plataforma evolucionó en secuencia hasta cubrir el ciclo completo del agente. En ambos, la entrega inicial fue pequeña y verificable, y la ampliación vino después.
Preguntas frecuentes
¿Necesito a alguien técnico en la empresa para evaluar un contrato de software?
No necesariamente. La revisión técnica del código o de la arquitectura se puede contratar. Lo que solo tú tienes es la respuesta a "qué está decidido y qué no". Pide al proveedor, por escrito, la lista de lo que consideró fuera del precio y de lo que supuso sobre los sistemas que ya usas. Esa lista es más útil que cualquier cláusula.
¿El precio cerrado no protege mejor mi caja?
Protege la caja, no necesariamente el resultado. La cifra está definida, pero lo que cabe en ella depende de lo bien descrito que estuviera el pedido, y lo que quedó fuera vuelve como adenda. Hay compradores que aceptan pagar una prima de riesgo por previsibilidad, como muestran las entrevistas de Lichtenstein y McDonnell. Es una elección legítima, siempre que se haga sabiendo qué cubre la prima.
¿Y si la integración con lo que ya uso resulta más complicada de lo previsto?
Es el caso más común de incertidumbre oculta, y por eso merece un tratamiento propio. Haz primero el descubrimiento, para que el proveedor vea el sistema existente antes de poner precio, y deja por horas con tope solo lo que no haya logrado aclarar. Si el tope se supera, te enteras pronto, en un bloque pequeño, y decides con datos.
El siguiente paso
Si tienes una propuesta sobre la mesa y no sabes si el formato encaja con lo que ya está decidido, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, ayuda a separar lo que se puede cerrar ahora de lo que todavía hay que descubrir, y sales con esa lista: habla con un arquitecto.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico