Precio cerrado o retainer para un SaaS: cuándo conviene cada uno

Elegir entre precio cerrado y retainer es elegir entre comprar un resultado definido por un precio fijo y comprar cada mes el tiempo de un equipo, sobre un backlog que no deja de cambiar. Con precio cerrado se fijan qué se entrega, cuándo y por cuánto, y el riesgo de la estimación pasa al proveedor. Con un retainer se fijan el coste mensual y el equipo, y lo que sale a producción puede cambiar de un mes a otro.

La pregunta le llega a un founder dos veces. Una antes del desarrollo, cuando un consejo o un inversor pide una sola cifra. Y otra después del lanzamiento, cuando el backlog es más largo que el presupuesto. En cada momento la respuesta correcta es distinta. Aquí comparamos los dos modelos como tiene que hacerlo quien compra: qué compras con cada uno, dónde falla cada uno y cómo saber, leyendo una propuesta, cuál de los dos te están vendiendo de verdad.

La respuesta corta: cuál elegir y cuándo

El precio cerrado encaja cuando lo que hay que desarrollar se puede describir entero antes de empezar, y un cambio a mitad de camino sería la excepción. Una web corporativa, una integración bien definida, una fase de discovery, una migración con un estado final conocido.

El retainer encaja cuando el producto ya está en producción, los usuarios te dicen qué hacer después y dentro de seis semanas la lista será otra. En medio queda la primera versión de un SaaS nuevo, donde ninguno de los dos modelos encaja del todo. Ahí funciona mejor una secuencia de ambos (lo vemos más abajo).

Precio cerrado y retainer, frente a frente

• Qué compras. Precio cerrado: una lista de entregables con criterios de aceptación. Retainer: el tiempo de un equipo cada mes, medido en horas, jornadas o personas.
• Qué queda fijo. Precio cerrado: precio, alcance y fecha, los tres. Retainer: el coste mensual y el equipo; el alcance se mueve.
• Quién asume el riesgo de la estimación. Precio cerrado: el proveedor, que lo mete en el precio como colchón. Retainer: tú, a través del número de meses que lleve el trabajo.
• Cómo se gestiona un cambio. Precio cerrado: una solicitud de cambio, presupuestada y firmada antes de seguir. Retainer: se reordena el backlog en la siguiente planificación.
• Sobre qué se discute. Precio cerrado: si una petición es un cambio o ya estaba en el alcance. Retainer: si el equipo entrega lo suficiente para lo que cuesta al mes.
• Forma del presupuesto. Precio cerrado: un total aprobado una vez, normalmente pagado por hitos. Retainer: un coste operativo que sigue hasta que una de las partes da el preaviso.
• Dónde funciona mejor. Precio cerrado: trabajos con un estado final conocido. Retainer: un producto con usuarios reales y un backlog que cambia.

Cuándo gana el precio cerrado

Cuando el estado final se puede poner por escrito

El precio cerrado funciona si los requisitos son lo bastante estables como para listarlos con criterios de aceptación. Una integración de pagos con un proveedor concreto. Una migración de datos de un esquema a otro. La reconstrucción de un producto existente, función por función. En todos estos casos la estimación es sobre todo una suma de tareas conocidas, y el proveedor puede presupuestarla sin un colchón grande.

Cuando quien aprueba quiere una sola cifra

Los consejos de administración, los departamentos de compras y las subvenciones aprueban totales. Un precio cerrado con pagos por hitos es el formato que ya saben firmar. Un retainer también se puede aprobar, pero se lee como un coste operativo sin final, y en una empresa que aún no ha decidido si el producto existirá dentro de un año es una conversación más difícil.

Cuando lo que compras es una decisión

La discovery es la compra a precio cerrado más limpia que hay: una duración fijada, un resultado definido (investigación, arquitectura, prototipo, un plan con costes) y un precio acordado de antemano. Convierte un desarrollo lleno de incógnitas en algo que dos partes pueden estimar. Cuánto debería costar, y qué rechazar, lo contamos en cuánto cuesta la fase de discovery en 2026.

Cuando el trabajo es corto

Cuanto más lejos está la fecha, peor es la estimación. En un estudio sobre más de 5.400 proyectos de IT, McKinsey y la Universidad de Oxford vieron que cada año adicional de duración prevista aumentaba los sobrecostes un 15% (McKinsey). Eran proyectos de más de 15 millones de dólares, mucho más grandes que un SaaS. Pero el mecanismo es el mismo a cualquier escala: cuanto más lejos queda la entrega, más cambia el mundo antes de llegar a ella. Un precio cerrado de seis semanas es una apuesta mucho más segura que uno de nueve meses.

Cuándo gana el retainer

Cuando la hoja de ruta la escriben los usuarios

Después del lanzamiento, la mejor guía para decidir qué hacer es lo que la gente hace con lo que has publicado. Con un retainer eso llega al equipo en la siguiente planificación. Con precio cerrado llega como solicitud de cambio, y cada solicitud de cambio es una pequeña negociación.

Cuando el alcance va a cambiar de todos modos

Según el Pulse of the Profession 2018 de PMI, el 52% de los proyectos terminados en los doce meses anteriores sufrió scope creep o cambios sin control, frente al 43% de cinco años antes (PMI). Si un cambio es tan probable, un contrato pensado para resistirlo gasta su energía en resistir. Martin Fowler ya lo dijo en 2003: el contrato de alcance cerrado pone a cliente y proveedor en bandos opuestos, discutiendo qué es un cambio y quién lo paga (Fowler, Scope Limbering).

Cuando la continuidad vale dinero

Un equipo que lleva seis meses en una base de código sabe dónde están las partes frágiles, qué tests importan y por qué un campo se llama como se llama. En una serie de proyectos a precio cerrado separados, ese conocimiento puede irse entre un contrato y el siguiente, y cada proyecto nuevo paga por reconstruirlo. Con un retainer, las mismas personas siguen en el mismo código.

Cuando el trabajo es un flujo constante

Parches de seguridad, actualizaciones de dependencias, trabajo de rendimiento, pequeñas correcciones, alguna función de vez en cuando. Nada de esto es lo bastante grande como para presupuestarlo aparte, y todo hay que hacerlo. Ese coste recurrente lo desglosamos en cuánto cuesta mantener un sitio web en 2026, y los rangos mensuales de los retainers de diseño en precios del retainer de product design.

Por qué la primera versión de un SaaS no encaja en ninguno

Un SaaS nuevo cae justo en el hueco entre los dos modelos. Su alcance es demasiado incierto para un contrato del todo cerrado: lo que aprendas en la cuarta semana cambiará la octava. Y es demasiado pronto para un retainer abierto: nadie ha usado aún el producto, y una cuota mensual sin una primera versión definida no te da ninguna fecha que exigir.

La salida es dejar de fijar precio, alcance y fecha a la vez. La alternativa de Fowler era fijar el presupuesto y la fecha de lanzamiento, y decidir juntos el mejor conjunto de funciones que cabe dentro (Fowler, Fixed Price). El Manifiesto Ágil lo resumía en una línea: la colaboración con el cliente por encima de la negociación contractual (Agile Manifesto). En el desarrollo de un SaaS, eso se traduce en una secuencia de tres contratos:

1. Una discovery a precio cerrado. Unas semanas, un precio fijo y un resultado que puedes llevar a cualquier proveedor: la primera versión puesta por escrito, una arquitectura y un plan con costes.
2. Una primera versión con presupuesto cerrado. Un precio y una fecha de lanzamiento, con una lista de funciones ordenada por prioridad en lugar de una congelada. Cuando entra algo nuevo, sale algo del mismo tamaño o pasa a después del lanzamiento. El contrato define la regla del intercambio, no cada función.
3. Un retainer después del lanzamiento. El mismo equipo con una cuota mensual, sobre un backlog al que ahora da forma el uso real, con preaviso para las dos partes.

Cada paso usa el modelo que encaja con la incertidumbre de ese momento. Y cada uno te deja una salida: el resultado de la discovery puede ir a otro proveedor, y el retainer se puede cerrar si el trabajo deja de valer la cuota. El coste de cada escenario lo estimamos en cuánto cuesta desarrollar un SaaS en 2026.

Cómo leer una propuesta con cada modelo

La etiqueta de una propuesta importa menos que sus cláusulas. Un "precio cerrado" con un alcance vago se comporta como un retainer, facturado a base de solicitudes de cambio. Un "retainer" sin informes no te deja juzgar la cuota. Cinco cosas que revisar:

• Los criterios de aceptación. En una propuesta a precio cerrado, cada entregable debería decir cómo sabrás que está terminado. Si pone "gestión de usuarios" y nada más, la discusión sobre qué incluye empieza el primer día.
• El proceso de cambio. Quién presupuesta un cambio, en cuánto tiempo y a qué tarifa por jornada. Un precio cerrado con un proceso de cambio lento o caro acaba por encima del presupuesto.
• El colchón. Un proveedor que asume el riesgo de la estimación lo mete en el precio. Pregunta cómo se construyó la estimación. Un total sin desglose esconde cuánto de él es reserva.
• Los informes del retainer. Qué se ha entregado cada mes, qué viene después y en qué se han ido las horas. Sin eso, no sabes si la cuota compra avance.
• Horas sin usar y preaviso. Si las horas sin usar se acumulan o caducan, y cuánto preaviso da cada parte. Juntas deciden lo que cuesta irse.

La estructura del contrato importa tanto como el modelo de precio. Un acuerdo marco con statements of work separados te deja llevar una discovery a precio cerrado y un retainer posterior con las mismas condiciones; comparamos los dos documentos en SOW y MSA. Para las cláusulas que conviene revisar antes de firmar, mira las 8 cláusulas a revisar.

Cómo se ve la secuencia en un desarrollo real

Pongamos un caso hipotético. Un founder tiene una idea B2B validada, una ronda seed y un consejo que quiere una fecha de lanzamiento. Una discovery a precio cerrado convierte la idea en una lista de funciones ordenada, una arquitectura y un presupuesto para la primera versión. La versión avanza con ese presupuesto cerrado y una fecha fija. A mitad de camino, un cliente piloto pide single sign-on, y una exportación de informes de tamaño parecido pasa a después del lanzamiento. La versión sale en la fecha prevista, con las funciones que más importaban en ese momento. Desde el lanzamiento, el mismo equipo pasa a un retainer, y la exportación es lo primero de su backlog.

Ningún contrato de esa secuencia intenta prever el producto entero. Cada uno pone precio solo a lo que se puede saber el día en que se firma.