Precio cerrado vs tiempo y materiales: qué contrato funciona de verdad para software a medida
El framework del fundador no técnico para elegir la estructura de contrato adecuada con un partner de software, y las cláusulas que hacen que el tiempo y materiales sea realmente responsable.
La primera vez que un fundador nos reenvía dos borradores de contrato y pregunta cuál firmar, ya sabemos cómo va a terminar la conversación. Un borrador es a precio cerrado: un número único, una lista de funcionalidades, una fecha de entrega. El otro es a tiempo y materiales: una tarifa por hora o por semana, una estimación blanda, una pedida de confianza. Le dijeron al fundador que el precio cerrado es más seguro porque limita la factura, y quiere que se lo confirmemos.
La mayoría de las veces le decimos lo contrario. Para software a medida en etapa inicial, tiempo y materiales con una estructura de milestones es el default sano. El precio cerrado gana en un conjunto reducido de casos que normalmente no se aplican, y cuando gana, hay que pagar de más para que sea honesto. El contrato que firmas para software a medida no es un instrumento financiero. Es el sistema operativo de la relación que estás a punto de construir.
Este es el framework que repasamos con cada fundador antes de cualquier firma.
Qué es cada contrato, en una frase
Precio cerrado significa que tú y el proveedor acuerdan un total fijo por un alcance definido, pagado contra milestones. El proveedor asume el riesgo de entrega. Si subestimó, es su problema.
Tiempo y materiales, abreviado T&M, significa que pagas por el tiempo que el equipo realmente dedica, normalmente facturado por semana o por sprint, con tarifas acordadas. El proveedor envía una factura por las horas trabajadas. Tú asumes el riesgo presupuestario. Si el trabajo dura más de lo esperado, la cuenta sigue corriendo.
Esa es la descripción de manual. También es donde la mayoría de los artículos sobre el tema se detienen, y por eso los fundadores firman el contrato equivocado. Las dos estructuras parecen simétricas en el papel. En la práctica crean incentivos completamente distintos, y esos incentivos moldean el producto que terminas recibiendo.
Las cuatro condiciones que hacen honesto el precio cerrado
El precio cerrado no es una mala estructura. Es una estructura que exige condiciones que la mayoría de los proyectos de software en etapa inicial no puede cumplir. Cuando estos cuatro puntos son verdaderos, el precio cerrado puede ser la elección correcta.
El alcance está realmente conocido. No “sabemos que queremos un marketplace”. Conocido significa: las pantallas están diseñadas, las integraciones están listadas, los edge cases están documentados, el modelo de datos está cerrado, la tasa a la que el cliente cambia de idea está cerca de cero. Si no puedes entregarle una carpeta a un desconocido y obtener de él una estimación parecida a la de tu proveedor, el alcance no está cerrado.
El trabajo es una commodity. Un sitio WordPress para una página institucional, un ajuste de tema Shopify, una app móvil de forma conocida para un negocio de forma conocida. Cosas que ya se construyeron miles de veces, donde el proveedor tiene un marco de referencia real. Cuanto más lejos estés de una commodity, más margen de riesgo necesita meter el proveedor en el número fijo para absorber las incógnitas. Ese margen es el precio que pagas por la transferencia de riesgo.
No vas a cambiar de idea. Si la única persona que puede modificar el alcance eres tú, y puedes prometer creíblemente que no lo harás, el precio cerrado se mantiene limpio. En el momento en que cambias de alcance, el precio cerrado se convierte en una sucesión de change orders, cada uno negociado bajo asimetría de información. Para el tercer change order, el contrato dejó de funcionar.
El proveedor construyó exactamente esto recientemente. No “algo parecido”. Esto. Un equipo que entregó la misma forma de producto a dos clientes anteriores puede cotizar a precio cerrado de forma honesta porque su estimación está anclada en dos cotizaciones pasadas que se confirmaron. Un equipo nuevo en el dominio está adivinando, y la adivinanza viene cargada de margen de riesgo.
Si no puedes defender los cuatro puntos ante un colega, el precio cerrado es la estructura equivocada para tu proyecto. El número en el contrato es ficción.
Las cuatro maneras en que el precio cerrado se rompe en la práctica
Los fundadores que firman contratos a precio cerrado en software a medida real casi siempre terminan en uno de estos modos de falla.
El proveedor infló el número, y pagaste caro por un riesgo que nunca se materializó. Un buen proveedor sabe que “construir un SaaS de gestión de propiedades” carga incógnitas desconocidas. Cotiza el número que le permite dormir tranquilo. Si todo va bien, acabas de pagar una prima del 30% al 60% por el privilegio de la certeza. Ese dinero habría rendido más en un proyecto T&M que terminara en el mismo lugar.
El proveedor subestimó, y ahora está perdiendo dinero contigo. El precio cerrado no alinea los incentivos de nadie cuando el proyecto entra en rojo. El único camino del proveedor de vuelta a margen es recortar: saltarse pruebas, reciclar código de un cliente anterior, entregar algo de lo que no estaría orgulloso, poner a un junior en un problema senior. No tienes visibilidad de nada de eso hasta que el producto se rompe en producción seis meses después.
El alcance crece y la relación se desmorona. El software de verdad se va descubriendo a sí mismo mientras se construye. Un fundador ve el segundo prototipo y se da cuenta de que el PRD que escribió al principio estaba equivocado. Bajo precio cerrado, cada nueva caída de la ficha se convierte en una negociación de contrato. El proveedor se vuelve un clipboard. Empiezan a odiarse antes de que el MVP salga.
El proveedor desaparece al 80% del proyecto. Ese es el peor modo de falla y el más común. El precio cerrado hace que la mayor parte del flujo de caja esté concentrada en los milestones tardíos. Cuando el proveedor ya cobró el grueso del trabajo fácil y lo que queda es la parte difícil y ambigua, irse es racional para él. Lo hemos visto pasar en tres software houses distintas con tres fundadores distintos. El patrón es idéntico: un kickoff brillante, demos semanales que se ven bien, y una caída silenciosa de atención a partir del cuarto mes.
Hemos escrito sobre cómo evaluar a la software house que va a firmar este contrato antes de que cualquier estructura contractual importe. Un mal partner te va a fallar con cualquiera de los dos contratos. La estructura de contrato hace que la falla ocurra más rápido o más despacio. No mueve el techo.
Por qué T&M es el default para software a medida
Time and materials tiene mala fama injustamente porque suena a cheque en blanco. En una estructura sana, es lo contrario.
T&M alinea los incentivos donde tienen que estar alineados. Al proveedor le pagan por entregar software funcionando cada sprint. A ti te pagan en forma de software funcionando cada sprint. Nadie está en posición de perder dinero contigo, así que nadie está en posición de recortar contigo. Cuando el alcance cambia, la conversación es “esto agrega dos semanas” y no “esto dispara una adenda contractual que va a tomar tres semanas en negociarse”. Las decisiones se toman más rápido. El producto sale mejor.
T&M también te expone la verdad del trabajo. Ves las horas, la velocidad, los trade-offs. Dentro de un proyecto a precio cerrado, el proveedor tiene incentivo para mantenerte fuera de la realidad de ingeniería, porque cada conversación sobre la realidad se vuelve renegociación. Dentro de un proyecto T&M, el proveedor tiene incentivo para meterte dentro de la realidad de ingeniería, porque así te quedas seguro de que la factura es justa.
Hay un costo real. T&M significa que tú cargas el riesgo presupuestario, y el presupuesto puede salirse. La forma de neutralizar ese riesgo no es precio cerrado. Es una estructura T&M con responsabilidad incorporada.
La estructura de contrato T&M que no te desangra
La mayoría de los contratos T&M están demasiado flojos. El proveedor envía factura cada semana, el fundador la paga, y a los tres meses nadie tiene una visión clara de qué se entregó realmente. Usamos una estructura más disciplinada con cada fundador con el que trabajamos. Son cinco cláusulas, todas negociables, ninguna exótica.
Tope por sprint. Define un máximo de horas por semana o por sprint. El proveedor no puede facturar por encima del tope sin un acuerdo escrito, y los excesos no se acumulan. Es un techo blando que mantiene al equipo enfocado en entregar lo más valioso en cada ciclo, en lugar de moler horas en el ticket que esté abierto.
Demo o no se factura. Cada sprint termina con una demo de lo que se construyó, funcionando. Si la demo no ocurre, ese sprint no es facturable. La cláusula suena agresiva en la negociación. En la práctica es lo que cualquier proveedor honesto ya hace, y la formalidad te protege en uno de cada cinco engagements donde el equipo empieza a saltarse demos hacia el tercer mes.
Derecho a pausar en cualquier milestone. Puedes detener el proyecto al final de cualquier sprint sin penalización, sin kill fee, sin clawback. Debes las horas ya trabajadas. Punto. Es la cláusula más importante del contrato. Convierte la relación en una sucesión de pequeñas apuestas, cada una revalidada por lo que el sprint anterior efectivamente entregó.
Código en tu repositorio desde el día uno. El codebase vive en tu organización de GitHub o GitLab, no en la del proveedor. Cada commit que el equipo empuja es tuyo de inmediato, no al final del proyecto. Hemos entrado en demasiadas situaciones donde un fundador descubrió, durante un divorcio con su proveedor, que no era dueño del código sobre el que su empresa funciona. Esta cláusula hace que ese divorcio sea mecánicamente posible.
Un log de decisiones, no un reporte de estatus. El proveedor mantiene un log corto y escrito de las decisiones tomadas en cada sprint y de los trade-offs detrás, en tu repositorio. No es un update de tickets cerrados. Es un registro de “elegimos Postgres por encima de MongoDB por X”, “diferimos el trabajo multi-tenant por Y”. El log es lo que le permite a un ingeniero futuro, incluido el que vaya a reemplazar a este equipo, entender por qué el sistema es como es. También es lo que hace que el eventual handover sea sobrevivible.
Un contrato T&M con estas cinco cláusulas te da casi toda la seguridad del precio cerrado, casi nada de su daño de incentivos, y un nivel de visibilidad sobre el trabajo que el precio cerrado activamente te oculta. A esto lo llamamos T&M con milestones, y le pedimos a cada fundador que negocie por esta estructura antes de que arranque cualquier trabajo.
Cuándo elegir precio cerrado de verdad (y qué pagar de más para hacerlo real)
Existe un caso reducido para precio cerrado incluso en software a medida real. Aplica cuando tienes un deadline externo duro que el proveedor no puede fallar, el alcance está extraordinariamente bien definido, y el proveedor ya construyó exactamente esta forma de cosa antes. Una fecha de go-live impuesta por un regulador, una integración con un cliente flagship con fecha de inicio fijada por contrato, un deck de demo para una reunión de board ya agendada.
En esos casos, el precio cerrado no se trata de ahorrar dinero. Se trata de comprar seguro de entrega. Para que ese seguro sea honesto, tres cosas tienen que ser ciertas.
El proveedor incorpora una prima de riesgo real, y tú la aceptas. Si la cotización se siente sospechosamente baja para precio cerrado, salte. El proveedor no entiende el trabajo o está planeando recortar.
Pre-negocias el protocolo de cambio de alcance antes de firmar. No “vamos a resolver los change orders cuando aparezcan”. Un proceso escrito que diga: change order por debajo de X dólares se aprueba por mail; por encima de X dispara una ventana de 48 horas para reprecificación y un re-baseline del cronograma. Eso vuelve los inevitables cambios de alcance manejables en lugar de relacionalmente fatales.
Mantienes al menos el 25% del valor del contrato en el milestone final, pagable solo contra entrega completa y un test de aceptación acordado. Esa es la palanca que evita la salida al 80%. El número que guardas al final es lo que el proveedor no puede permitirse dejar en la mesa.
Si no consigues los tres, el contrato a precio cerrado es teatro. Cambia a T&M con milestones y deja de negociar contra ti mismo.
FAQ rápido
¿Cuál es la diferencia entre precio cerrado y tiempo y materiales en lenguaje simple?
Precio cerrado es un número único para un alcance acordado. Tiempo y materiales es el reloj corriendo sobre el tiempo que el equipo efectivamente dedica. El proveedor asume el riesgo de entrega en precio cerrado. Tú asumes el riesgo de presupuesto en T&M, y la mayor parte se neutraliza con las cláusulas correctas.
¿Cuál es la diferencia entre precio cerrado y un retainer de fee fija?
Un retainer es una fee fija recurrente para un alcance recurrente, normalmente continuo en lugar de atado a un entregable específico. Está más cerca de un T&M con tope que de un precio cerrado tipo proyecto. Los retainers funcionan bien después de que la primera versión del producto está en el aire, cuando el equipo está iterando en lugar de construir desde cero.
¿Existe un modelo híbrido?
Sí, y a veces es la respuesta correcta. El patrón más útil que vemos es una fase de discovery corta a precio cerrado (dos a cuatro semanas, con alcance limitado a producir una arquitectura escrita y una especificación de producto firmada) seguida de T&M con milestones para la construcción. La discovery sale barata, el alcance queda realmente conocido al final, y empiezas el trabajo real con un proveedor que ya probó saber escuchar.
¿Quién decide cuál firmamos?
Tú, no el proveedor. Los proveedores prefieren precio cerrado cuando intentan amarrar ingreso y T&M cuando creen que el alcance va a crecer. La estructura correcta es la que encaja con el proyecto, no la que encaja con el trimestre del proveedor.
¿El tipo de contrato debería cambiar a medida que la empresa crece?
Probablemente. El software a medida en etapa inicial, con un producto que aún se está descubriendo, casi siempre quiere T&M con milestones. Una vez que un sistema está en producción y el equipo está iterando sobre una forma conocida, los retainers a precio cerrado pueden funcionar bien. Es la misma lógica que se aplica a contratar un CTO antes de tiempo: el contrato es una herramienta, no una identidad.
El contrato es la relación. Elige la estructura que te deje construir lo que de verdad quieres, con la gente en quien de verdad confías. Después negocia las cláusulas que hacen honesta cualquier estructura. El número de la página uno importa menos que las cinco líneas de la página siete.