Contratos de Desarrollo de Software: Qué Revisar Antes de Firmar

La mayoría de los contratos de desarrollo de software se firman en un estado de optimismo. Ambas partes están entusiasmadas con el proyecto, la relación es cálida y el futuro parece despejado. Nadie lee con detenimiento la cláusula de resolución de disputas cuando cree que nunca habrá una disputa. Nadie examina la cesión de PI cuando asume que la agencia hará lo correcto.

El problema es que los contratos no se redactan para los buenos tiempos. Son el único documento que regula lo que ocurre cuando las cosas salen mal: cuando el alcance se desborda, cuando la agencia incumple plazos, cuando necesitas terminar el contrato, cuando descubres que el código se construyó sobre una biblioteca con una licencia incompatible. Para cuando necesitas el contrato, ya estás en una situación difícil. Si no lo leíste correctamente antes de firmarlo, estás a punto de descubrir exactamente cuánto margen de negociación no tienes.

Hemos tenido clientes que llegaron a nosotros habiendo perdido propiedad intelectual que creían que era suya, que no podían terminar un contrato fallido sin pagar decenas de miles en honorarios de preaviso, y que descubrieron a mitad del proyecto que los acuerdos de confidencialidad que habían firmado en realidad no cubrían su concepto de negocio. Cada uno de ellos habría detectado el problema si hubiera sabido qué buscar antes de firmar.

Esta guía cubre las cláusulas que importan, las que se pasan por alto con frecuencia y las disposiciones que debes negarte a aceptar. Está escrita para fundadores, gerentes de producto y responsables de compras — no para abogados — y está diseñada para darte la fluidez suficiente para revisar un contrato de forma inteligente, incluso si contratas a un asesor jurídico para la revisión final.

---

Titularidad de la Propiedad Intelectual

Esta es la cláusula más importante en cualquier contrato de desarrollo de software, y es la que con más frecuencia se malinterpreta.

El estándar que debes esperar es la cesión completa de los derechos de propiedad intelectual al realizar el pago final. Esto significa que cuando hayas pagado, el código, la documentación, los activos de diseño y cualquier obra derivada te pertenecen de forma absoluta. No a la agencia. No bajo una licencia. A ti.

Lo que esa cláusula debería decir, en términos sencillos: la agencia te cede de forma irrevocable todos los derechos de propiedad intelectual sobre los entregables, incluidos los derechos de autor, al recibir el pago final. No debe haber excepciones, derechos retenidos ni lenguaje de licencia que se haga pasar por propiedad.

Lo que debes vigilar:

• Lenguaje de "licencia de uso" en lugar de cesión. Si el contrato dice que la agencia "te otorga una licencia" para usar el software, no lo posees. Lo estás alquilando. La agencia conserva la propiedad y puede, en teoría, revocar o modificar los términos. Esta redacción a veces está disfrazada para parecer propiedad. Lee cada palabra.
• Derechos retenidos sobre "PI preexistente". Las agencias conservan legítimamente la propiedad de herramientas, marcos de trabajo, bibliotecas y plantillas base que aportan a un proyecto. Eso es justo. Lo que no es aceptable es que la PI preexistente esté definida de forma tan amplia que abarque la funcionalidad central de lo que encargaste. Pídeles que especifiquen exactamente qué PI preexistente se retiene y asegúrate de tener una licencia irrevocable y libre de regalías para usarla dentro de tu producto.
• Cesión de PI condicional. Algunos contratos incluyen cláusulas en las que la PI "revierte" a la agencia si no realizas un pago o incumples algún término. Lo tratamos en la sección de señales de alerta. Nunca lo aceptes.
• Obra hecha por encargo vs. cesión. En algunas jurisdicciones, el software creado por un contratista no califica automáticamente como "obra hecha por encargo". Una cláusula de cesión clara evita esta ambigüedad por completo. Asegúrate de que el contrato use lenguaje explícito de cesión independientemente de la jurisdicción.

Pide a la agencia que confirme por escrito, antes de firmar, que serás el propietario absoluto de la PI una vez realizado el pago. Cualquier titubeo es una señal que vale la pena investigar.

---

Alcance del Trabajo

Un alcance de trabajo vago es una fuga presupuestaria esperando abrirse. El Alcance del Trabajo (SOW, por sus siglas en inglés) es el documento que define exactamente qué construye la agencia para ti, y si es impreciso, cada desacuerdo sobre lo que está "incluido" se resolverá en dirección a costos adicionales.

Lo que incluye un SOW bien definido:

• Una lista específica de funcionalidades, no una descripción general del producto
• Criterios de aceptación para cada entregable — ¿cómo sabrán ambos cuándo algo está terminado?
• Decisiones sobre la plataforma y el stack tecnológico
• Integraciones con terceros, con sistemas nombrados específicamente
• Expectativas de rendimiento cuando sea relevante (tiempos de carga de página, umbrales de usuarios concurrentes)
• Lo que queda explícitamente fuera del alcance

El proceso de solicitud de cambios importa tanto como el SOW en sí. Ningún proyecto sobrevive al contacto con la realidad sin cambios. La pregunta es si los cambios se gestionan de forma transparente o si se utilizan como mecanismo para extraer ingresos adicionales sin que lo entiendas plenamente. Un buen contrato especifica un proceso formal de solicitud de cambios: el cliente presenta una solicitud de cambio por escrito, la agencia proporciona una evaluación de impacto escrita que cubre tiempo y costo, y el trabajo en el cambio solo comienza después de que lo hayas aprobado por escrito.

Desconfía de cualquier contrato que no defina cómo se gestionan los cambios. "Acomodaremos cambios razonables sin costo adicional" no es un proceso — es una promesa vaga que se evapora en el momento en que tú y la agencia no se ponen de acuerdo en qué significa "razonable".

El SOW debe ser un anexo o apéndice adjunto al contrato, no estar incorporado en un correo electrónico de ventas. Si solo está en una cadena de correos, formalízalo antes de firmar el acuerdo principal.

---

Condiciones de Pago

La estructura de pagos es donde se establecen las dinámicas de poder de un proyecto. Cómo y cuándo pagas determina cuánto margen de maniobra conservas durante todo el contrato.

Las tres estructuras principales:

• Basado en hitos. Pago vinculado a entregables definidos. Pagas cuando se completa y acepta algo específico. Este es el modelo más favorable para el cliente en proyectos de precio fijo, ya que tu dinero siempre está respaldado por valor recibido.
• Tiempo y materiales. Pagas por las horas trabajadas, generalmente semanalmente o mensualmente en diferido. Es estándar para contratos de mantenimiento continuos y desarrollo iterativo. El riesgo es el costo ilimitado si el alcance no se gestiona con rigor.
• Entregable con pago anticipado. Pagas un precio fijo por un resultado definido. Es razonable para trabajos pequeños y bien definidos.

Las reglas que recomendamos:

Nunca pagues más del 30–40 % del valor total del contrato por adelantado. Un depósito inicial del 20–30 % es estándar y razonable — cubre el costo de incorporación de la agencia y les da confianza de que vas en serio. Cualquier monto superior al 40 % por adelantado inclina el poder a su favor. Si un proyecto fracasa o no se entrega, recuperar un pago anticipado del 60 % mediante acciones legales es costoso, lento e incierto.

Los pagos por hitos deben estar vinculados a la aceptación, no al paso del tiempo. "Facturaremos el último viernes de cada mes" no es facturación por hitos — es facturación por tiempo etiquetada como hitos. Los criterios de aceptación del SOW se convierten en la condición para el pago.

Las cláusulas de retención valen la pena solicitarlas en contratos grandes. Una retención del 5–10 % del pago final, mantenida durante 30–60 días después del lanzamiento, incentiva a la agencia a corregir errores post-lanzamiento con prontitud. No todas las agencias aceptarán esto, pero vale la pena negociarlo.

---

Confidencialidad y NDA

La mayoría de los contratos de desarrollo de software incluyen una cláusula de confidencialidad. La pregunta es si cubre lo que realmente necesitas proteger.

Lo que debe estar cubierto: tu concepto de negocio, tus datos, tu arquitectura técnica, cualquier secreto comercial que divulgues durante el descubrimiento, los datos de tus clientes y la existencia del contrato en sí si eso es comercialmente sensible.

NDA mutuo vs. unilateral: En la mayoría de los casos, un NDA mutuo es apropiado. La agencia puede compartir contigo información sobre sus métodos, estructuras de precios o herramientas durante el contrato — un NDA unilateral que solo te protege a ti puede generar fricciones. Los NDA mutuos son estándar y no deberían ser un punto de conflicto.

Duración: Las obligaciones de confidencialidad deben sobrevivir al contrato. Una cláusula que dice que la confidencialidad aplica "durante la vigencia de este acuerdo" no te protege después de que termine el contrato. El estándar es de dos a cinco años post-terminación para información confidencial general, sin límite de tiempo para los secretos comerciales.

Subcontratistas: Si la agencia utiliza subcontratistas o desarrolladores externos en tu proyecto, asegúrate de que la cláusula de confidencialidad exija explícitamente que la agencia vincule a esas partes con obligaciones equivalentes. Una cláusula de confidencialidad que solo cubre a los empleados propios de la agencia es una brecha.

---

Garantías y Responsabilidad

Los contratos de desarrollo de software con frecuencia contienen garantías que suenan exhaustivas pero ofrecen poca protección práctica, y cláusulas de responsabilidad que o bien faltan por completo o están fuertemente inclinadas en contra del cliente.

Cómo debe ser una garantía de software: Una disposición de garantía razonable compromete a la agencia a corregir los defectos del software que se reporten dentro de un período definido después del lanzamiento — típicamente entre 30 y 90 días. Debe cubrir defectos que provoquen que el software no funcione materialmente según lo especificado en el SOW. No debería requerir que pruebes que el error existía en el lanzamiento, solo que existe dentro del período de garantía.

Lo que una garantía no es: Ninguna agencia creíble garantizará ni debería garantizar que el software no tiene errores. El software es complejo. Lo que pueden garantizar razonablemente es que corregirán los errores en el período especificado sin costo adicional. Ten cuidado con las garantías de gran alcance que prometen perfección — o son inaplicables o se usarán para argumentar que cada problema está fuera del alcance.

Límites de responsabilidad: La mayoría de los contratos incluyen un límite a la responsabilidad total de la agencia, típicamente igual a los honorarios pagados en virtud del contrato. Esto es estándar y ampliamente aceptable. Lo que no es aceptable es un límite de responsabilidad de una cifra nominal (por ejemplo, €500 o €1,000) en un contrato de €50,000, o un límite combinado con una exclusión general de pérdidas consecuentes que te impediría recuperar una compensación significativa por una entrega fallida.

Indemnización: El contrato debe incluir una cláusula de indemnización mutua que cubra reclamaciones de terceros por propiedad intelectual. En concreto, la agencia debe indemnizarte si el software que entrega infringe los derechos de PI de un tercero. También debes verificar si estás indemnizando a la agencia por cualquier PI que aportes tú — esto es razonable, pero asegúrate de que el alcance se limite a los activos que realmente contribuyes.

---

Terminación

Tu derecho a salir de un contrato que no está funcionando es una de las protecciones más importantes en cualquier contrato de servicio, y es una que los clientes frecuentemente no negocian antes de firmar.

Derecho a terminar por conveniencia: Debes tener el derecho de terminar el contrato sin causa, con preaviso razonable. Típicamente, 30 días es el estándar. Algunos contratos incluyen solo la terminación por causa — lo que significa que solo puedes salir si la agencia ha incumplido materialmente el contrato. Esto te deja atrapado en una relación fallida a menos que puedas probar el incumplimiento, lo que a menudo es difícil y lleva tiempo demostrar.

Lo que recibes al terminar: El contrato debe indicar claramente que, al terminar, recibes: todo el código desarrollado hasta la fecha, en un estado entregable; toda la documentación; credenciales de acceso para cualquier entorno, repositorio o servicio configurado en tu nombre; y un plan de transición claro. Una agencia que retiene el código hasta que se resuelva una disputa tiene un poder significativo sobre ti. No lo aceptes.

Períodos de preaviso y pagos al terminar: Si terminas por conveniencia, debes esperar pagar por el trabajo completado hasta la fecha de terminación. Lo que no debes aceptar es el requisito de pagar por trabajo aún no iniciado, o una "tarifa de cancelación" que equivale a un porcentaje significativo del valor restante del contrato. Algunos contratos incluyen daños liquidados por terminación — revísalos con cuidado.

Terminación por causa: También debes tener el derecho de terminar de inmediato, sin preaviso, si la agencia comete un incumplimiento material que no se subsana dentro de un plazo razonable (típicamente 14–21 días después de la notificación escrita).

---

Resolución de Disputas

Las disputas en el desarrollo de software son comunes — sobre alcance, calidad, plazos, pago y PI. Cómo se resuelve una disputa, dónde se resuelve y a qué costo puede importar tanto como el resultado.

Jurisdicción: Para contratos nacionales, asegúrate de que la ley aplicable y la jurisdicción correspondan a tu domicilio. Para contratos internacionales, este es un punto de negociación material. Una agencia con sede en Europa del Este o Asia del Sur puede proponer su jurisdicción local. La implicación práctica es que si necesitas ejecutar una sentencia, debes hacerlo en su país — lo que puede ser costoso, lento o prácticamente imposible.

Proceso de escalamiento: Los buenos contratos incluyen un proceso de escalamiento por etapas: discusión informal entre los líderes del proyecto, luego escalamiento a alta dirección, luego mediación formal, luego arbitraje o litigio. Esto es sensato y rentable — la mayoría de las disputas se pueden resolver sin procedimientos formales si existe un proceso estructurado.

Arbitraje vs. litigio: El arbitraje es generalmente más rápido, menos costoso y más privado que el litigio. Para disputas por debajo de cierto umbral (a menudo entre €50,000 y €100,000), el costo del arbitraje es proporcional. Asegúrate de que cualquier cláusula de arbitraje especifique un organismo arbitral reconocido y una sede de arbitraje en tu jurisdicción.

Nota internacional: Si contratas con una agencia fuera de tu jurisdicción, considera exigir que el contrato se rija por la ley de Inglaterra y Gales u otra jurisdicción de derecho consuetudinario internacionalmente neutral. Esto te da acceso a un derecho comercial bien desarrollado y a un régimen de ejecución predecible.

---

Acuerdo de Tratamiento de Datos (RGPD)

Si el software que se está desarrollando procesará datos personales — de tus clientes, tu personal o cualquier individuo en el EEE o el Reino Unido — tienes la obligación legal de contar con un Acuerdo de Tratamiento de Datos (DPA, por sus siglas en inglés) con cualquier parte que procese esos datos en tu nombre.

Esto no es opcional. Es un requisito en virtud del RGPD del Reino Unido y del RGPD de la UE, y la ausencia de un DPA te expone a riesgos regulatorios si alguna vez se produce una violación de datos o una auditoría de una autoridad de supervisión.

Quién es quién: En casi todas las relaciones de desarrollo de software, tú eres el responsable del tratamiento — determinas la finalidad y los medios del tratamiento. La agencia es el encargado del tratamiento — procesa los datos de acuerdo con tus instrucciones. El DPA debe reflejar esto con claridad.

Lo que debe cubrir el DPA:

• Las categorías de datos personales que se procesan y las finalidades del tratamiento
• Las obligaciones de la agencia de procesar datos solo según tus instrucciones documentadas
• Medidas de seguridad técnicas y organizativas apropiadas
• Restricciones sobre el subtratamiento (la agencia no puede transferir tus datos a un tercero sin tu autorización)
• Asistencia con solicitudes de interesados y notificación de brechas de seguridad
• Eliminación o devolución de datos personales al finalizar el contrato
• Derechos de auditoría

Si una agencia se niega a firmar un DPA o afirma que no es necesario para un contrato de desarrollo, trátalo como una señal de alerta grave. Incluso en un contexto de desarrollo, los datos personales a menudo se cargan en entornos de prueba — y esos datos deben estar protegidos.

---

Cláusulas de Alerta Roja que Debes Rechazar

Algunos términos contractuales no son simplemente desfavorables — son disposiciones que los clientes experimentados aprenden a identificar y rechazar. Estas son las cláusulas que parecen inofensivas durante la fase optimista de la firma y se vuelven dañinas cuando las cosas salen mal.

PI que revierte por pago tardío. Cualquier cláusula que transfiera la titularidad de la PI de vuelta a la agencia si realizas un pago tardío, incluso temporalmente, le da a la agencia una opción nuclear sobre tu producto. Una disputa de pago — que puede ocurrir por razones legítimas — debe resolverse mediante mecanismos de recuperación de pago, no mediante la recuperación de la PI de algo por lo que ya has pagado en gran parte.

Responsabilidad ilimitada del cliente. Algunos contratos incluyen cláusulas en las que el cliente indemniza ampliamente a la agencia por cualquier pérdida derivada del proyecto. Esto puede incluir pérdidas causadas por los propios errores de la agencia. Ningún cliente debe aceptar una responsabilidad ilimitada ni indemnizaciones que se extiendan más allá de los activos e información que contribuye directamente.

Sin derecho a terminar sin causa. Si no puedes salir del contrato sin demostrar que la agencia lo incumplió, has renunciado a tu capacidad de responder a un contrato fallido sin entrar en una disputa legal. Insiste siempre en un derecho de terminación por conveniencia.

Sin acceso al entorno de staging. Esta es una señal de alerta práctica más que legal. Si el contrato no te garantiza acceso a un entorno de staging durante todo el desarrollo, no tendrás visibilidad independiente de lo que se está construyendo hasta que la agencia decida mostrártelo. Insiste en el acceso continuo.

Renovación automática con largos períodos de preaviso. Los contratos de mantenimiento que se renuevan automáticamente por períodos de 12 meses con ventanas de cancelación de 90 días están diseñados para atrapar a los clientes en acuerdos de los que quieren salir. Un preaviso mensual de 30 días en un contrato mensual es el estándar.

Cláusulas de no solicitud amplias. Muchas agencias incluyen cláusulas que te impiden contratar a sus desarrolladores durante un período después del contrato. Una cláusula de no solicitud restringida que cubra a los desarrolladores directamente asignados a tu proyecto durante 12 meses es razonable. Una cláusula amplia que cubra a todo el personal de la agencia durante 24 meses es un intento de proteger su reserva de talento a tu costa.

---

Cómo Están Estructurados Nuestros Contratos en Cyberbeak

No somos neutrales en este tema — somos una agencia de desarrollo de software y tenemos una opinión sobre cómo deben funcionar los contratos. Creemos que vale la pena ser transparentes sobre cómo abordamos los nuestros.

Nuestros acuerdos estándar incluyen la cesión completa de la PI al cliente al recibir el pago final. No hay derechos retenidos más allá de las bibliotecas y herramientas preexistentes estándar, que se enumeran y están cubiertas por una licencia irrevocable. Utilizamos estructuras de pago basadas en hitos para proyectos de precio fijo, con hitos vinculados a criterios de aceptación acordados en el SOW. No solicitamos más del 30 % por adelantado.

Cada contrato con tratamiento de datos personales incluye un DPA como estándar. La confidencialidad es mutua. Nuestro límite de responsabilidad se establece en los honorarios pagados en virtud del contrato, con exclusiones estándar por fraude y conducta dolosa. Los clientes tienen un derecho de terminación por conveniencia de 30 días. Al terminar, todo el código, la documentación y las credenciales se transfieren en un plazo de cinco días hábiles.

Incluimos una garantía de corrección de defectos de 60 días post-lanzamiento en todos los proyectos de precio fijo.

Creemos que estos términos son justos para ambas partes y nos sentimos cómodos con que los clientes los revisen con un asesor jurídico. Si una agencia prospectiva objeta alguna de estas disposiciones, vale la pena preguntarle por qué.

---

Preguntas Frecuentes

¿Necesito un asesor jurídico para revisar un contrato de desarrollo de software?

Para cualquier contrato superior a €15,000–€20,000, lo recomendamos firmemente. Un asesor jurídico comercial con experiencia en contratos tecnológicos puede revisar un contrato estándar de desarrollo de software en una o dos horas. El costo suele ser de €300–€600. Dado lo que está en juego — tu PI, tu capacidad de salir, tus obligaciones de datos — es una de las inversiones con mayor retorno que puedes hacer. Para contratos más pequeños, leer esta guía y aplicarla tú mismo puede ser suficiente, pero la revisión profesional nunca es un desperdicio.

¿Qué pasa si la agencia no negocia los términos del contrato?

La mayoría de las agencias de buena reputación negociarán en puntos materiales. Si una agencia se niega a discutir la cesión de PI, la responsabilidad o los derechos de terminación, eso te dice algo importante sobre cómo abordan las relaciones con los clientes en general. Una resistencia estilística menor es normal — una negativa total a negociar protecciones sustantivas es una señal de alerta. Si genuinamente tienen un formulario estándar no negociable, pídeles que expliquen por escrito cada cláusula sobre la que tengas dudas. Sus explicaciones te dirán mucho.

¿Qué pasa con los acuerdos verbales y las conversaciones por correo electrónico?

Los acuerdos verbales son legalmente vinculantes en la mayoría de las jurisdicciones, pero son extremadamente difíciles de hacer cumplir porque no hay un registro claro de lo que se acordó. Las conversaciones por correo electrónico tienen más peso y pueden constituir un acuerdo vinculante en algunas circunstancias, pero crean ambigüedad sobre el alcance y los términos. La única posición segura es asegurarse de que cada término material — alcance, pago, PI, terminación — quede recogido en un acuerdo escrito firmado antes de que comience el trabajo. Si una agencia comienza a trabajar sobre la base de una autorización verbal y las cosas salen mal, es posible que tengas un recurso muy limitado.

¿Puedo usar un contrato de plantilla estándar en lugar de los términos de la agencia?

Sí, y en muchos casos es preferible. Si encargas software con regularidad, contar con tus propios términos estándar redactados por un asesor jurídico una vez y utilizados de forma consistente en todos los contratos te da una base conocida. La agencia puede solicitar modificaciones, y eso es una negociación — pero comenzar desde tu propia plantilla significa empezar desde términos estructurados a tu favor. También hay plantillas disponibles en organizaciones como TechUK y la Law Society, aunque estas deben ser revisadas por un asesor jurídico para asegurarse de que reflejen tus circunstancias específicas.

---

Lograr que el contrato sea correcto no se trata de desconfianza. Se trata de asegurarse de que ambas partes tienen el mismo entendimiento de lo que han acordado, y de que existe un proceso claro y justo para manejar las cosas que inevitablemente resultan diferentes de lo planeado.

Si estás evaluando un contrato de desarrollo de software y quieres entender cómo están estructurados nuestros acuerdos, o si tienes preguntas sobre lo que términos contractuales específicos significan en la práctica, estamos encantados de tener esa conversación. Contáctanos — sin compromiso, sin discurso de ventas, solo una discusión directa sobre cómo son los términos justos.