Precio cerrado o por horas: qué te conviene al encargar un programa

Al encargar un programa, el precio cerrado te conviene cuando se puede describir lo que quieres antes de empezar, que es lo normal en una pyme. El precio por horas te conviene cuando nadie sabe todavía qué hay que hacer, o para cambios pequeños y continuos una vez el programa está en marcha. En los dos casos, lo que te protege es un alcance escrito.

Mi primera llamada de venta de verdad la hice con el presupuesto apuntado en una libreta, desglosado por horas.

Me temblaba la voz. El cliente escuchó el número, miró el desglose y me dijo algo parecido a "eso no te lo voy a pagar, pero me interesa". Llegamos a un acuerdo. Y aprendí algo que no se me ha olvidado: cuando enseñas horas, el cliente discute horas. Cuando enseñas lo que resuelves, discute si le compensa.

Desde entonces trabajo a precio cerrado. Pero no siempre es lo mejor para el cliente, y conviene saber cuándo.

¿Qué diferencia hay entre los dos modelos?

Con precio cerrado pagas una cantidad fija por un resultado definido. Con precio por horas pagas el tiempo que se dedica, sea cual sea el resultado.

	Precio cerrado	Por horas
Sabes cuánto vas a pagar	Sí, desde el principio	No, lo sabes al final
Quién asume el riesgo de que tarde más	El desarrollador	Tú
Hace falta definir mucho antes	Sí	No tanto
Cambiar de idea a mitad	Se presupuesta aparte	Se paga en horas, sin más
Incentivo del desarrollador	Terminar bien y rápido	Echar horas
Encaja con	Proyectos con objetivo claro	Exploración, soporte, cambios sueltos

La fila del incentivo es la que menos se comenta y la que más importa. Porque por horas, al desarrollador le conviene, aunque no quiera, que las cosas tarden. A precio cerrado, le conviene que salgan bien a la primera, porque cada arreglo lo paga él.

¿Cuándo te conviene el precio cerrado?

Cuando puedes contar lo que necesitas en una conversación de una hora. Y con una clínica, un taller o una distribuidora, casi siempre se puede.

"Quiero que los pedidos del WhatsApp entren solos, que salga el albarán, que el repartidor lo firme en el móvil y que se genere la factura." Eso se puede describir, dividir en partes y presupuestar. Y si se puede presupuestar, no hay ninguna razón para que tú asumas el riesgo de que el desarrollador se lo haya calculado mal.

Lo que necesitas para que un precio cerrado sea justo:

1. Un alcance escrito, con lo que entra y, sobre todo, lo que no entra.
2. Entregas por partes, para ver avances cada semana y no todo al final.
3. Un criterio claro de "terminado". Por ejemplo, que se pueda facturar un mes completo sin tocar el Excel.
4. Un plazo de garantía en el que los fallos se arreglan sin coste.

Pero si el presupuesto que te mandan es una línea con un número, eso no es un precio cerrado. Es una apuesta. Un presupuesto de verdad se parece más a un plano que a un albarán.

¿Cuándo te conviene pagar por horas?

Cuando ni tú ni el desarrollador sabéis todavía qué hay que hacer. Forzar un precio cerrado ahí hace que el desarrollador infle el número para cubrirse, y pagas de más.

Casos en los que yo recomendaría horas:

• Investigar si algo es posible. Por ejemplo, si un programa antiguo tiene forma de exportar los datos.
• Mantenimiento y cambios pequeños una vez el programa ya funciona.
• Proyectos en los que el propio negocio está cambiando cada mes.
• Soporte puntual, como una revisión de seguridad o una migración de servidor.

Para el mantenimiento, lo habitual es una cuota mensual con unas horas incluidas o una bolsa de horas que se va consumiendo. Lo explico en cuánto cuesta mantener un software a medida al mes.

¿Qué pasa si a mitad del proyecto quiero cambiar algo?

Se habla, se presupuesta y se decide antes de hacerlo. Esa es la regla, y protege a los dos.

Todo proyecto tiene su momento de "ya que estás". Ya que estás con los pedidos, méteme el control de stock. Ya que estás con la agenda, que mande también la encuesta de satisfacción. Son peticiones razonables. Pero el problema llega cuando se hacen sin hablar de precio ni de plazo.

El alcance escrito no está para decir que no, está para que los dos sepáis cuándo algo es nuevo. Cuando lo es, hay tres opciones:

1. Se añade, con su precio y su plazo, y se firma el cambio.
2. Se cambia por otra cosa del alcance que ya no hace falta, sin coste extra.
3. Se deja para una segunda fase, cuando lo primero ya funcione.

Y la opción 2 es la que más uso. A mitad de proyecto, casi siempre hay algo que parecía necesario y ya no lo es.

¿Y si me piden rebajar el precio?

Si el precio no te encaja, lo sano es bajar el alcance, no el precio. Diez cosas por un precio o cinco por la mitad.

Yo cometí el error de rebajar para cerrar una vez. Cobré casi la mitad de lo habitual y ese proyecto me dio más trabajo que ninguno. Lo cuento en rebajar el precio para cerrar te trae al peor cliente. Desde el lado del cliente, la lección es la misma: si alguien te rebaja mucho sin quitar nada, pregúntate de dónde va a sacar las horas.

¿Cómo se calcula un precio cerrado justo?

Con un análisis previo, no a ojo. Hay que entender el proceso, el volumen y lo que te cuesta hoy hacerlo a mano.

Por eso antes de dar un precio dedico una semana a entender tu empresa. De esa semana sale un documento con lo que se va a hacer, en qué orden y por cuánto. Te cuento cómo es en qué pasa en la primera semana de un proyecto conmigo. Los rangos que se ven en el mercado, para que tengas una referencia, están en cuánto cuesta un software a medida.

Entonces, si alguien te da un precio cerrado sin haber visto cómo trabajas, desconfía. O se ha pasado, o se va a quedar corto y lo vas a notar.

Pide siempre que te escriban lo que no entra, porque ahí es donde se esconden las discusiones. Y si quieres un alcance así para tu proyecto, reserva una llamada de 30 minutos y empezamos por ahí.