Contratos con agencias de software: 8 cláusulas a revisar en 2026

La línea más cara de un contrato con una agencia de software suele ser la que nadie lee. Un fundador paga una factura de seis cifras, lanza el producto, luego intenta pasar a otro equipo y descubre que la agencia sigue siendo dueña del código. Ese es el patrón detrás de la mayoría de las señales de alerta en estos contratos: las cláusulas que deciden propiedad, pago y salida están debajo del texto sobre el alcance, y solo aparecen cuando algo ya salió mal.

Construimos productos SaaS, y también los heredamos de otros equipos. Hemos leído suficientes de estos acuerdos como para ver repetirse las mismas ocho señales de alerta. Ninguna necesita un título en derecho para detectarse. Necesita que sepas dónde mirar. Esto no es asesoramiento legal: para cualquier contrato que comprometa dinero real, pide a un abogado cualificado que lo revise antes de firmar. Lo que sigue es cómo se comportan estas cláusulas de verdad cuando el proyecto está en marcha, para que sepas qué frases pasar primero a tu abogado.

Señal 1: sin cesión explícita de la PI, solo "work made for hire"

Es el malentendido más caro en los contratos de software. Muchos acuerdos etiquetan los entregables como "work made for hire" y se detienen ahí. Bajo la ley de derechos de autor de Estados Unidos, esa fórmula por sí sola a menudo no transfiere la propiedad del software encargado. La doctrina del work made for hire está pensada para empleados y una breve lista de categorías específicas, y el código por encargo suele quedar fuera. Los tribunales han rechazado repetidamente tratar el software como work made for hire solo porque el contrato lo dijera (CCBJournal, Association of Corporate Counsel).

La solución es una cláusula de cesión separada y explícita: al pago final, la agencia te cede todo derecho, título e interés sobre el trabajo producido, incluidos copyright, patentes y secretos comerciales. Pagar por el trabajo no significa, por defecto, ser su dueño. Si el contrato tiene la etiqueta "work made for hire" pero ninguna cesión de respaldo, es una señal de alerta, no una formalidad.

Señal 2: pago total por adelantado o atado al calendario

Un proveedor que pide el 100% antes de un trabajo significativo, o que ata los pagos a fechas en lugar de a entregables aceptados, ha eliminado su propio incentivo para terminar. Una estructura sana contempla un anticipo del 20-30%, un 40-50% repartido en dos o tres hitos ligados a funcionalidades completadas, y un 20-30% en la aceptación final. Cada hito debería corresponder a algo verificable, no a una semana en el calendario.

La trampa más frecuente es el fundador que paga el 50% por adelantado por un "descuento". El descuento casi siempre es menor que el coste de rehacer cuando el proyecto se desvía. El pago ligado a hitos mantiene honestas a ambas partes.

Señal 3: sin criterios de aceptación, sin definición de "terminado"

Si el contrato nunca dice qué significa "terminado", cada plazo se vuelve negociable y cada disputa se vuelve tu palabra contra la suya. Los criterios de aceptación son la lista que define un entregable completado. Si la agencia no sabe escribirlos antes de empezar, todavía no entiende el trabajo.

Busca también una ventana de revisión definida, a menudo cinco días hábiles, en la que aceptas un hito o planteas problemas concretos. Un contrato donde la aceptación no tiene plazo, o donde el silencio no cuenta ni como aceptación ni como rechazo, deja el proyecto en un limbo permanente. Los requisitos y la gestión del alcance siguen siendo las primeras razones por las que fallan los proyectos de software: la investigación CHAOS del Standish Group mantiene desde hace años el éxito pleno por debajo de uno de cada tres proyectos, con requisitos poco claros y scope creep entre las causas principales (ReqSuite, sobre Standish CHAOS).

Señal 4: sin acceso al código durante el desarrollo

Deberías ver el repositorio desde el primer día, no recibir un archivo zip al final. Cuando el código vive solo en las máquinas de la agencia hasta la entrega final, no puedes verificar el avance, no puedes traer una segunda opinión y no tienes palanca si la relación se rompe a mitad del proyecto. Exige tu propia organización de control de versiones, con la agencia trabajando dentro de ella. Un contrato que entrega el código "al completar" y no da acceso intermedio es un mecanismo de bloqueo disfrazado de comodidad.

Señal 5: sin garantía y sin ventana para corregir defectos

El software sale con errores. La pregunta es quién los corrige, y durante cuánto tiempo, tras el lanzamiento. Un contrato sin periodo de garantía y sin un nivel de servicio para defectos trata el día de la entrega como el fin de toda responsabilidad. Un término razonable es una ventana definida, a menudo de 30 a 90 días, en la que la agencia corrige defectos en el alcance entregado sin coste adicional. Sin ella, el primer error en producción se convierte en un nuevo encargo de pago.

Señal 6: bloqueo por infraestructura propietaria

Algunas agencias atan los entregables a su propio hosting, a sus librerías internas o a un CMS propietario que no puedes ejecutar sin ellas. El código puede ser "tuyo" sobre el papel y seguir siendo inutilizable por otro equipo. Haz una pregunta directa antes de firmar: puedo tomar todo el código y ejecutarlo con otro equipo mañana. Si la respuesta no es un sí inmediato, estás ante un bloqueo. Aquí importan más las herramientas estándar y portables que cualquier cláusula.

Señal 7: cambios sin definir y scope creep silencioso

Los requisitos cambian en casi todos los proyectos. El contrato debería decir cómo. Un proceso claro de solicitud de cambios define cómo se cotiza, aprueba y factura el trabajo nuevo antes de empezar. Cuando ese proceso falta, ocurre una de dos cosas: la agencia absorbe los cambios y la calidad baja, o los factura en silencio y el importe se dispara. Alrededor de tres de cada cuatro proyectos de software sufren scope creep, así que trata el proceso de cambios como un término central, no como texto de relleno.

Señal 8: responsabilidad e indemnización a un solo lado

Lee la sección de responsabilidad desde tu lado de la mesa. Un desequilibrio común: la agencia limita su propia responsabilidad a los honorarios pagados (o menos), mientras te pide una indemnización amplia. Esa combinación significa que cargas con la mayor parte del riesgo por un trabajo que no escribiste. No eliminarás todo el riesgo de un contrato de servicios, y no deberías intentarlo. Sí deberías asegurarte de que la responsabilidad no sea gravemente asimétrica y de que cualquier indemnización que concedas esté ligada a tu propia conducta, no a la de la agencia.

Cómo arreglar lo que ya está

Si ya firmaste y ahora reconoces una señal de alerta, no estás sin opciones. Pide una modificación por escrito sobre la cláusula concreta: cesión de la PI al pago final, ventana para corregir defectos, acceso al repositorio. Las agencias que pretenden hacer buen trabajo suelen aceptar, porque la petición es razonable y la alternativa es un cliente nervioso. Una agencia que rechaza una cesión limpia de la PI después de que hayas pagado te está diciendo algo que vale la pena escuchar. Ata cualquier trabajo o hito nuevo a la modificación, para que haya un momento natural para firmarla.

Cómo prevenirlo la próxima vez

La prevención empieza antes del contrato. Un brief ajustado y un alcance claro reducen la superficie donde estas cláusulas pueden hacerte daño. Escribir un pliego específico que atraiga a los proveedores adecuados filtra a las agencias cuyo margen depende de la ambigüedad. Entender cómo contratar un estudio de product engineering y qué modelo encaja con tu etapa te dice cómo se ve un contrato justo antes de que llegue a tu bandeja de entrada. Ten una lista corta y fija: cesión explícita de la PI, pagos por hitos, criterios de aceptación, acceso en vivo al repo, garantía de defectos, infraestructura portable, proceso de cambios y responsabilidad equilibrada. Ocho líneas. Léelas cada vez.