Presupuesto cerrado vs. cobro por horas: qué conviene según el proyecto

Cuando llega el momento de contratar un desarrollo de software, una de las primeras decisiones no es técnica ni de alcance: es cómo se va a pagar. Los dos modelos más comunes —presupuesto cerrado y cobro por horas— no son simplemente dos formas de facturar. Representan dos lógicas distintas de gestionar el riesgo, la incertidumbre y la relación con el proveedor.

Elegir mal el modelo no arruina un proyecto por sí solo, pero genera fricciones que se acumulan: expectativas desalineadas sobre qué está incluido, discusiones sobre si un cambio es "adicional" o "parte del alcance original", y una relación que empieza comercial y se vuelve tensa cuando los supuestos iniciales no se sostienen.

Este artículo explica las ventajas y desventajas de cada modelo, y ofrece criterios para decidir cuál conviene según las características de tu proyecto.

Presupuesto cerrado: cuándo funciona y cuándo no

En un modelo de presupuesto cerrado —también llamado precio fijo o llave en mano—, el proveedor se compromete a entregar un alcance definido por un monto total acordado de antemano. El riesgo de que el desarrollo lleve más tiempo del estimado lo asume el proveedor; el cliente sabe exactamente cuánto va a pagar, siempre que el alcance no cambie.

Ventajas

• Previsibilidad financiera: sabés cuánto va a costar el proyecto antes de empezar. Esto es particularmente útil cuando el presupuesto es limitado y necesitás certeza para aprobar la inversión.
• Incentivo a definir el alcance: como cualquier cambio respecto de lo acordado se considera adicional, ambas partes tienen interés en documentar bien qué entra y qué no. Esa claridad inicial reduce ambigüedades.
• Menor carga de supervisión: no necesitás monitorear cuántas horas se consumen por semana; el foco está en si los entregables cumplen con lo acordado.

Desventajas

• Rigidez ante cambios: si durante el desarrollo surge una necesidad nueva —porque los usuarios prueban algo y piden ajustes, o porque el negocio cambia una prioridad—, cada modificación implica renegociar. El proyecto puede volverse una secuencia de "adicionales" que erosionan la relación.
• Sobreestimación defensiva: como el proveedor asume el riesgo de que algo lleve más tiempo, suele incorporar un margen de seguridad en la estimación. En proyectos de alcance incierto, ese margen puede ser considerable.
• Calidad bajo presión: si el desarrollo se extiende más de lo previsto y el proveedor está perdiendo dinero, el incentivo es terminar rápido, no terminar bien. Las pruebas, la documentación y los detalles de experiencia de usuario son lo primero que se recorta.

Cobro por horas: cuándo funciona y cuándo no

En el modelo de cobro por horas —también llamado tiempo y materiales—, el cliente paga por el tiempo efectivamente trabajado, a una tarifa acordada. El alcance puede evolucionar durante el proyecto, y las prioridades se ajustan semana a semana según lo que el negocio necesita en ese momento.

Ventajas

• Flexibilidad real: si aparece información nueva —un feedback de usuarios, un cambio en el mercado, un aprendizaje técnico—, se puede incorporar sin renegociar el contrato. El equipo ajusta el rumbo y el costo refleja el esfuerzo real.
• Incentivo alineado con la calidad: como el proveedor cobra por el tiempo trabajado, no tiene presión por recortar etapas para proteger su margen. Si algo necesita más pruebas o una revisión adicional, se hace.
• Transparencia: el cliente ve semana a semana en qué se invirtió el tiempo. Esto permite tomar decisiones informadas sobre si vale la pena seguir invirtiendo en una dirección o conviene pivotar.

Desventajas

• Incertidumbre sobre el costo total: sin un techo claro, el presupuesto puede crecer más de lo previsto. Esto requiere que el cliente tenga un mecanismo para monitorear el avance y decidir cuándo frenar o redirigir.
• Requiere más involucramiento del cliente: para que el modelo funcione, alguien del lado del negocio debe estar disponible para priorizar, revisar entregas parciales y tomar decisiones semana a semana. Si esa persona no existe o no tiene tiempo, el equipo avanza sin dirección clara y las horas se consumen en iteraciones que no suman valor.
• Riesgo de ineficiencia si no hay supervisión: un proveedor poco ético puede extender tareas más de lo necesario. Un proveedor ético pero sin dirección clara también puede consumir horas en direcciones que después se descartan.

El factor decisivo: el nivel de certeza del alcance

La pregunta que define el modelo no es "¿cuánto querés gastar?" sino "¿cuán seguro estás de lo que necesitás construir?".

Si podés describir con precisión qué hace cada funcionalidad, qué datos maneja, cómo se ve y qué condiciones debe cumplir para considerarse terminada, un presupuesto cerrado es viable. El proveedor puede estimar con márgenes razonables y el riesgo de desviación es bajo.

Si en cambio sabés qué problema querés resolver pero no exactamente cómo debería verse la solución —porque dependés de feedback de usuarios, porque el proceso que querés digitalizar tiene muchas excepciones, o porque es la primera vez que encarás un proyecto de este tipo—, el cobro por horas te da el espacio para descubrir la solución correcta sin estar atado a un alcance que probablemente era incorrecto desde el principio.

Modelos híbridos: una tercera opción

No todo es blanco o negro. Muchos proyectos funcionan bien con modelos combinados:

• Presupuesto cerrado para una fase inicial acotada (descubrimiento, prototipo, MVP) y cobro por horas para las iteraciones posteriores, cuando ya hay más información sobre lo que realmente se necesita.
• Presupuesto cerrado con un colchón de horas para cambios menores, acordado de antemano. Por ejemplo: el alcance principal a precio fijo, más un fondo de horas para ajustes que no justifican renegociar el contrato entero.
• Cobro por horas con un techo mensual, que le da al cliente control sobre el gasto sin sacrificar la flexibilidad de priorizar semana a semana.

Cómo llevar esta decisión a la práctica

Antes de pedir cotizaciones:

1. Escribí el alcance con el máximo detalle que puedas. Si al leerlo vos mismo encontrás frases como "el sistema debería permitir gestionar..." sin especificar qué significa "gestionar", el alcance no está listo para un presupuesto cerrado.
2. Identificá qué partes del proyecto son más inciertas. Tal vez la funcionalidad principal está clara pero las integraciones no. Eso ya te da una pista de qué modelo conviene para cada parte.
3. Preguntale al proveedor qué modelo recomienda para tu caso y por qué. Si siempre recomienda el mismo sin importar el proyecto, es una señal de que está optimizando para su comodidad, no para la tuya.

Relacionado: antes de definir el modelo de cobro, conviene tener claro cómo estimar el costo real de un proyecto de software, porque muchas de las variables que afectan la estimación también afectan qué modelo de cobro es más adecuado. Y si todavía estás en la etapa de decidir qué construir, revisá qué validar antes de desarrollar una aplicación.

Podés encontrar más contenido sobre modelos de contratación y presupuesto en la categoría de costos y presupuestos.