Vas a encargar una web, una app o un MVP y te llegan dos tipos de propuesta. Una dice «12.000 €, entrega en 8 semanas». La otra dice «65 €/hora, estimamos entre 150 y 250 horas». Sobre el papel pueden costar lo mismo. En la práctica son dos contratos distintos, con incentivos distintos, y elegir mal es la forma más habitual de que un proyecto de software acabe en disgusto.
Nosotros trabajamos con precios cerrados y lo decimos en la portada. Pero este artículo no va de eso: va de que entiendas qué estás firmando en cada caso, porque hay proyectos donde la bolsa de horas es la opción honesta.
Qué es cada modelo, sin adornos
Presupuesto cerrado: acordáis un alcance concreto y un precio fijo. Si el proveedor tarda más de lo previsto, el sobrecoste es suyo. El riesgo de ejecución lo asume quien ejecuta.
Bolsa de horas (o time and materials): pagas por tiempo trabajado, normalmente con una estimación orientativa. Si el proyecto se alarga, el sobrecoste es tuyo. El riesgo de ejecución lo asumes tú.
Ninguno de los dos es «el bueno». La pregunta correcta es: ¿quién está en mejor posición para controlar el riesgo de este proyecto?
Lo que la bolsa de horas no te cuenta
El argumento de venta de las horas es la flexibilidad: «así puedes cambiar de opinión por el camino». Es cierto. Lo que no se dice tan alto:
- La estimación no es un compromiso. «Entre 150 y 250 horas» significa que 250 tampoco es un techo. Cuando se agotan, la conversación no es «habéis incumplido», sino «¿ampliamos la bolsa?». Y a mitad de proyecto, con el software a medias, tu capacidad de negociar es mínima.
- El incentivo económico apunta en tu contra. No hace falta mala fe: simplemente, nadie que cobra por hora tiene prisa estructural por terminar. La eficiencia depende de la ética del proveedor, no del contrato.
- El presupuesto lo controlas tú… en teoría. En la práctica, decidir qué se recorta exige criterio técnico. Si supieras priorizar deuda técnica frente a funcionalidad, probablemente no estarías contratando fuera.
Lo que el precio cerrado te exige a ti
El precio cerrado tampoco es magia. Funciona solo si se dan dos condiciones, y las dos dependen también de ti:
- Un alcance definido de verdad. «Una web corporativa de unas 6 páginas con formulario de contacto» se puede cerrar. «Una plataforma que iremos viendo» no. Si el proveedor te cierra un precio sobre un alcance difuso, desconfía: o ha inflado el precio para cubrirse, o vais a pelear cada cambio.
- Disciplina con los cambios. Todo lo que aparezca después del acuerdo se presupuesta aparte. Eso no es rigidez: es lo que hace que el precio inicial signifique algo. Un proveedor serio te dirá que no a mitad de proyecto, y eso es una señal buena, no mala.
A cambio, obtienes lo que una pyme más necesita al encargar software: una cifra que puedes llevar a tu plan de tesorería y un proveedor con incentivo real para acabar.
Cuándo tiene sentido cada uno
| Situación | Modelo razonable |
|---|---|
| Web corporativa, e-commerce, MVP con alcance definible | Precio cerrado |
| Producto nuevo con alcance acotable en fases | Precio cerrado por fase |
| Evolución continua de un producto ya vivo | Bolsa de horas o cuota mensual |
| Rescate de un proyecto ajeno sin documentación | Horas para el diagnóstico, cierre después |
| Investigación pura, sin entregable definible | Horas, con revisiones frecuentes |
El patrón: cuando el alcance se puede definir, el precio cerrado te protege. Cuando genuinamente no se puede —mantenimiento, exploración, código heredado que nadie conoce—, forzar un precio fijo solo infla el precio con el colchón del riesgo. Por eso un MVP bien planteado se cierra (el alcance de 6 semanas se define en la primera), pero su evolución posterior se suele acordar de otra manera.
Cinco preguntas antes de firmar
- ¿Qué pasa exactamente si el proyecto se alarga? La respuesta te dice quién asume el riesgo, sea cual sea el nombre del modelo.
- ¿Qué incluye el precio y, sobre todo, qué no? Hosting, dominios, licencias, soporte tras la entrega, correcciones de errores. Los disgustos viven en el «no incluye».
- ¿Cómo se gestionan los cambios de alcance? Si la respuesta es «somos flexibles», insiste hasta obtener un mecanismo concreto.
- ¿De quién es el código y desde cuándo? Repositorio a tu nombre desde el primer día. Sin excepciones, en ningún modelo.
- ¿Cada cuánto veo avances funcionando? Una demo periódica de software real —no capturas, no diapositivas— es tu mejor seguro en ambos modelos.
Nuestra postura, en corto
Publicamos precios «desde» por servicio y cerramos la cifra final antes de empezar, con el alcance por escrito. No porque las horas sean una estafa —no lo son—, sino porque para la mayoría de encargos de pyme el alcance sí se puede definir, y entonces el precio cerrado es el reparto de riesgo más justo: tú pones el qué, nosotros respondemos del cuánto y del cuándo.
Si tienes un proyecto y no sabes ni por dónde empezar a acotarlo, cuéntanoslo. Te diremos qué se puede cerrar, qué no, y por qué — también si la respuesta honesta es que aún no necesitas contratar a nadie.