Contrato de desarrollo de software: guía completa y plantilla gratuita

La mayoría de los proyectos de software no fracasan porque los desarrolladores fueran malos programando. Fracasan porque nadie escribió qué significa "terminado". El informe CHAOS del Standish Group sitúa la tasa de éxito de los proyectos de software en apenas el 31 %, y los desacuerdos sobre el alcance, la titularidad de la PI poco clara y las condiciones de pago en disputa son los culpables más habituales.

En realidad, un contrato de desarrollo de software resuelve todo eso antes de que comience el trabajo. Es el contrato entre un cliente y un desarrollador (o agencia) que define qué se construye, quién es su titular, cuánto cuesta y qué ocurre cuando algo se tuerce. Sin él, dependes de la buena fe y de la memoria, y los tribunales no aceptan ninguna de las dos. En la práctica, la mayoría de las disputas no son por mala intención, sino por recuerdos distintos de la misma conversación.

Esta guía cubre todo: cuándo necesitas un contrato de desarrollo de software, los cuatro tipos de contrato y cuándo usar cada uno, todas las cláusulas que realmente importan y una plantilla gratuita descargable que puedes personalizar para tu proyecto. Si ya conoces los conceptos básicos y quieres ir directamente a la plantilla, salta a la sección de la plantilla. De lo contrario, el contexto importa, especialmente la sección de PI, donde la mayoría de los contratos fallan en silencio. La cuestión es esta: corregir una vulnerabilidad descubierta en producción cuesta aproximadamente 30 veces más que detectarla durante el desarrollo, según una investigación de NIST. Esa estadística por sí sola justifica cada línea de tu cláusula de pruebas de aceptación. Para una visión más amplia de cómo difieren los acuerdos de los contratos, nuestra guía sobre contratos vs. acuerdos cubre las distinciones legales que conviene conocer. Cuando estés listo para redactar, nuestra guía cómo redactar un contrato ofrece un marco paso a paso.

Un contrato de desarrollo de software (SDA, por sus siglas en inglés) es un contrato legalmente vinculante entre un cliente y un desarrollador o empresa de desarrollo de software. Define el alcance del trabajo, la estructura de pagos, el calendario de entregas, la titularidad de la propiedad intelectual, las condiciones de confidencialidad y qué ocurre si cualquiera de las partes necesita salir del acuerdo.

El SDA no es una propuesta, ni un brief de proyecto, ni un hilo de Slack confirmando el trabajo. Sinceramente, he visto los tres intentados como "contratos", y ninguno acabó bien. Es el registro legal formal de lo que ambas partes acordaron antes de que comenzara el desarrollo. Una vez firmado, es el documento al que recurrirás si hay una disputa, y el documento que un tribunal leerá si llega a eso.

Qué cubre un SDA

Un contrato de desarrollo de software bien redactado abordará:

• Alcance del trabajo: lo que el desarrollador construirá, con suficiente detalle para que un tercero pueda evaluar su finalización
• Entregables e hitos: qué se entrega, en qué forma y para cuándo
• Condiciones de pago: tarifa total, calendario de pagos y qué desencadena cada pago
• Titularidad de la PI: quién posee el código una vez escrito
• Confidencialidad: qué información propietaria debe mantener en privado cada parte
• Pruebas de aceptación: cómo evalúa el cliente si el software entregado cumple los requisitos
• Garantías: qué garantiza el desarrollador sobre la funcionalidad del software
• Condiciones de terminación: cómo cualquiera de las partes puede poner fin al contrato y qué ocurre con el trabajo ya completado

Algunos clientes confunden el SDA con un Statement of Work (declaración de trabajo). Hay solapamiento, pero no son lo mismo. Dicho esto, la distinción importa más de lo que la mayoría cree. La relación entre un MSA y un SOW explica cómo funcionan estos documentos juntos en colaboraciones a largo plazo.

Respuesta corta: siempre que pagues a alguien para construir software, o que te paguen por construirlo.

El contrato importa tanto si contratas a un freelancer en solitario para un proyecto de dos semanas como si contratas a una agencia de 20 personas para construir un producto durante 12 meses. Cambia la escala; la necesidad de condiciones por escrito no.

Deberías tener un contrato de desarrollo de software cuando:

• Estás externalizando el desarrollo de software: especialmente a equipos remotos o en el extranjero, donde las diferencias de jurisdicción complican los acuerdos informales
• Se está construyendo software a medida: cuanto más a medida sea el trabajo, más explícitamente debe documentarse la titularidad de la PI
• Existen varias fases de desarrollo: los pagos por hitos requieren criterios de aceptación por escrito para activar cada fase
• Hay datos o sistemas sensibles involucrados: cualquier proyecto que toque datos de clientes necesita cláusulas de confidencialidad y seguridad
• Estás construyendo sobre marcos propietarios: el código preexistente que se incorpora a entregables a medida crea cuestiones de titularidad confusas sin un contrato claro
• Estás trabajando entre fronteras: la ley aplicable y la jurisdicción deben nombrarse cuando el desarrollador y el cliente están en países diferentes

La respuesta corta sobre cuándo puedes saltarte un SDA completo: casi nunca. Incluso un trabajo muy breve y de bajo valor regulado por un acuerdo marco de servicios completo debería tener un SOW por escrito adjunto. Pero incluso entonces, la mayoría de los abogados te diría que hagas el papeleo. La cuestión es esta: el coste de redactar un SOW de una página es trivial comparado con el coste de una disputa de alcance en un proyecto "sencillo".

No hay una única plantilla de SDA que sirva para cada colaboración, y quien te diga lo contrario te está vendiendo algo. La estructura del contrato debe encajar con cómo se valora y delimita el proyecto, y elegir la estructura equivocada crea incentivos que juegan en contra de los buenos resultados.

Contratos de precio fijo

Un SDA de precio fijo funciona cuando los requisitos del proyecto son estables y bien comprendidos antes de que comience el desarrollo. El desarrollador se compromete a entregar un alcance definido por una tarifa total acordada. La certeza presupuestaria es el principal atractivo para los clientes. El riesgo: si los requisitos resultan estar poco especificados, el desarrollador absorbe el sobrecoste o comienzan las disputas.

Contratos de tiempo y materiales

Los contratos T&M tienen sentido para proyectos exploratorios, productos en fase inicial o cualquier situación en la que no se pueda definir el alcance completo de antemano. El cliente paga por las horas reales trabajadas a las tarifas acordadas. Obtienes flexibilidad; el contrapeso es la incertidumbre de coste. Los topes presupuestarios y los techos mensuales ayudan a gestionar ese riesgo.

Acuerdos de equipo dedicado

Para las empresas que necesitan un equipo de ingeniería remoto estable (en lugar de la entrega de un proyecto puntual), un acuerdo de equipo dedicado fija las condiciones de una relación continua. La gestión de contratos para empresas IT suele implicar este modelo cuando se trabaja con socios de externalización.

Estructura MSA + SOW

Las colaboraciones más grandes suelen separar el marco legal maestro (MSA) de las condiciones específicas del proyecto (SOW). El MSA cubre la PI, la confidencialidad, la responsabilidad y la resolución de disputas una sola vez; cada SOW cubre los entregables específicos, el calendario y el pago de un proyecto concreto.

No todas las cláusulas tienen el mismo peso. En mi opinión, estas cinco son donde los contratos viven o mueren. Son aquellas en las que el lenguaje ausente o vago provoca disputas reales.

1. alcance del trabajo y entregables

Describe qué se construye con suficiente detalle para que alguien ajeno al proyecto pueda evaluar si se entregó. Aquí encajan los requisitos funcionales, las especificaciones técnicas, los servicios soportados y los puntos de referencia de rendimiento. Nombra explícitamente qué queda fuera del alcance.

El alcance vago es la fuente más común de disputas de software. La realidad es que la mayoría de los clientes piensan que fueron claros, la mayoría de los desarrolladores piensan que entendieron, y ninguno tiene razón. "Construir un sitio web" no es un alcance. "Construir una aplicación responsiva en React/Next.js con las funciones enumeradas en el Anexo A, que supere puntuaciones de Lighthouse de rendimiento de 90+ en móvil" sí es un alcance.

2. condiciones de pago y calendario de hitos

Enumera cada pago: importe, evento desencadenante y método de pago. Los pagos por hitos deben estar vinculados a entregables aceptados, no solo a fechas del calendario. Define la moneda, el plazo de pago (Net-15 o Net-30 es estándar) y la penalización por demora.

3. titularidad de la propiedad intelectual

Esta es la cláusula que la mayoría de los clientes lee demasiado deprisa. ¿Quién es el titular del código a medida? ¿Quién es el titular de cualquier código preexistente que el desarrollador incorpore? ¿Está cubierto el software de código abierto? La sección de PI del SDA determina quién puede usar, modificar, vender o licenciar el software tras la entrega. Si te equivocas aquí, las consecuencias son caras: véase el caso Cadence v. Avanti en la sección de PI más abajo.

4. confidencialidad

El SDA debe incluir obligaciones de confidencialidad mutuas. El desarrollador no puede divulgar datos del cliente ni lógica empresarial propietaria; el cliente no puede divulgar los procesos o herramientas propietarias del desarrollador. Para condiciones más sólidas de NDA en un acuerdo independiente, vale la pena leer junto con esta la guía cómo crear un NDA seguro y la guía de NDA para contratistas en empresas de software.

5. pruebas de aceptación

Define cómo el cliente revisa y acepta cada entregable. La ventana de revisión (5 a 10 días hábiles es habitual), el formato de la retroalimentación, los criterios para aprobar y qué ocurre si el cliente no responde dentro de la ventana de revisión (aceptación tácita).

6. garantías

El desarrollador debe garantizar que el software funcionará según lo especificado, que el código es original (o está debidamente licenciado) y que la entrega no infringirá derechos de PI de terceros. Un período de garantía para correcciones de errores tras la entrega (normalmente 30 a 90 días) protege al cliente de defectos descubiertos tras el lanzamiento.

7. condiciones de terminación

Cualquiera de las partes debe poder salir con un preaviso razonable. Define el plazo de preaviso (30 días es estándar), qué ocurre con el trabajo en curso y cómo se calcula el pago final en caso de terminación anticipada. Una cláusula de terminación por causa (que cubra incumplimiento sustancial, insolvencia o impago) debe estar separada de la terminación por conveniencia.

8. ley aplicable y jurisdicción

Nombra el país y el estado/región cuya ley rige el contrato. Cuando el desarrollador y el cliente están en países diferentes, esta cláusula decide qué tribunales conocerían una disputa. No la dejes fuera porque parezca formal: es una de las cláusulas más importantes en la práctica en una colaboración transfronteriza.

Usa esta plantilla como base para tu contrato. El coste medio de crear un contrato sencillo es de 6.900 dólares, y los contratos de complejidad media cuestan unos 21.300 dólares, según World Commerce & Contracting. Una plantilla no solo ahorra tiempo: ahorra dinero. Sustituye todos los campos entre corchetes por tus condiciones específicas. Para proyectos complejos, contrata a un abogado de software para revisar la versión final, especialmente las secciones de PI y garantías.

Para las empresas IT que gestionan contratos con varios socios de desarrollo, centralizar todos los SDA en un único sistema de gestión documental (con historial de versiones y firmas a prueba de manipulaciones) elimina el caos de enviar documentos de Word de un lado a otro por correo electrónico.

La plantilla anterior tiene más de una docena de campos por completar. Así puedes abordar cada uno sin dejar huecos que generen disputas más adelante.

Paso 1: define el alcance antes de tocar el contrato

No abras la plantilla hasta que hayas documentado lo que el software realmente debe hacer. Requisitos funcionales, restricciones técnicas, servicios soportados, dependencias de integración, todo. La sección de alcance del SDA es solo tan buena como el documento de especificación que la respalda.

Para proyectos complejos, adjunta la especificación completa como Anexo A y haz referencia a ella desde la cláusula de alcance. Esto mantiene legible el contrato principal mientras el detalle técnico completo queda legalmente adjunto.

Paso 2: construye el calendario de hitos

Trabaja hacia atrás desde la fecha de entrega. Divide el proyecto en fases (descubrimiento, diseño, desarrollo, pruebas, despliegue) y asigna un importe en dólares y una fecha de vencimiento a cada una. Los pagos por fase deben coincidir aproximadamente con el valor entregado en cada etapa.

Un aviso justo: esto lleva más tiempo del que la mayoría de las partes espera, especialmente en las primeras colaboraciones. Sinceramente, he visto a equipos presupuestar 20 minutos y necesitar dos horas. Reserva 1 a 2 horas con ambas partes presentes para acertar con los hitos y los pagos.

Paso 3: aborda explícitamente la titularidad de la PI

Lee la Sección 3 con cuidado y rellena todos los huecos. Si el desarrollador está usando marcos o herramientas propietarias que construyó antes de este proyecto, enuméralos en la exclusión de trabajo preexistente. Si estás usando bibliotecas de código abierto, nombra las licencias.

La cesión de trabajo a medida (Sección 3.1) suele ser la cláusula más importante para los clientes: es lo que transfiere la titularidad del código entregado del desarrollador a ti. No la dejes vaga.

Paso 4: fija la ventana y los criterios de aceptación

Decide la ventana de revisión antes de rellenarla. Diez días hábiles es habitual. Dos semanas dan a los clientes ocupados tiempo suficiente para probar realmente el entregable; cualquier cosa más corta tiende a generar disputas cuando los revisores están de viaje o, de otro modo, ocupados.

Para la Sección 5, los criterios de aceptación pertenecen al Anexo A. Escribe criterios específicos y comprobables: "La aplicación móvil carga el panel en menos de 3 segundos en una conexión 4G" supera a "la aplicación debe ser rápida".

Paso 5: elige la ley aplicable de forma deliberada

Para proyectos nacionales, usa el estado/país de origen del desarrollador (están más familiarizados con los tribunales locales). Para proyectos transfronterizos, cualquiera de las partes puede preferir una jurisdicción neutral. La ley de Delaware es habitual para contratos tecnológicos con base en EE. UU.; la ley inglesa se usa con frecuencia para acuerdos tecnológicos internacionales. Elijas lo que elijas, ambas partes deben acordarlo explícitamente: no dejes esto en blanco.

Paso 6: firma con una eSignature conforme

Una imagen escaneada de una firma manuscrita en un PDF es legalmente endeble en la mayoría de las jurisdicciones. Las firmas electrónicas que generan un hash del documento y un certificado de finalización con sello de tiempo son mucho más difíciles de repudiar. Bajo la Ley ESIGN y UETA en Estados Unidos, y eIDAS en la Unión Europea, las firmas electrónicas tienen plena fuerza legal para los acuerdos comerciales. El servicio de firma debería vincular cada firma al hash criptográfico del documento, de modo que cualquier alteración tras la firma sea detectable de inmediato.

La mayoría de las plantillas cubren lo básico. Estas son las cláusulas que se quedan fuera de los contratos baratos o redactados deprisa, y suelen importar más cuando algo va mal. Dicho esto, en la práctica, las cláusulas que omites son siempre las que acabas necesitando.

Pruebas de aceptación con criterios de aprobado/suspenso

La Sección 5 de la plantilla anterior define *cuándo* y *cómo* el cliente revisa los entregables. Lo que la mayoría de los contratos omite: los criterios reales para aprobar. Sin puntos de referencia medibles de aprobado/suspenso, la aceptación se convierte en una negociación. El cliente siempre puede alegar que el software no es "lo bastante bueno". Escribe criterios objetivos en el Anexo A antes de que comience el desarrollo.

Custodia del código fuente

Si tu negocio depende de software a medida y el desarrollador cierra, necesitas acceso al código fuente. Una cláusula de custodia (escrow) del código fuente exige que el desarrollador deposite el código fuente en un agente de custodia neutral. Si el desarrollador cesa operaciones o incumple sustancialmente el contrato, la custodia libera el código al cliente. La mayoría de los clientes nunca piensan en pedir esto, hasta que lo necesitan. La cuestión es esta: la custodia no es paranoia cuando tu negocio depende de código a medida.

Período de responsabilidad tras la entrega

La Sección 7 limita la responsabilidad total, pero muchas plantillas no abordan la ventana temporal. ¿Cuándo termina la responsabilidad? Si un defecto causa pérdida de datos 18 meses después de la entrega, ¿sigue siendo responsable el desarrollador? Define el período de garantía y la ventana de responsabilidad post-garantía explícitamente. Tras el período de garantía, la única obligación del desarrollador es típicamente abordar los defectos que causó, no los errores introducidos por modificaciones del cliente.

Proceso de control de cambios

La Sección 9 exige una Orden de Cambio firmada para los cambios de alcance. Lo que la mayoría de los contratos omite: definir quién tiene autoridad para firmar Órdenes de Cambio. Si un jefe de proyecto del lado del cliente solicita verbalmente una nueva función y el desarrollador la construye, ¿se le debe el pago al desarrollador? Solo si se siguió el proceso de Orden de Cambio. Nombra roles específicos (no individuos, cuyos cargos cambian) que tengan autoridad para autorizar cambios.

Cumplimiento de licencias de código abierto

La Linux Foundation informa de que el 92 % del software comercial contiene componentes de código abierto. La licencia de cada componente impone condiciones sobre cómo puede usarse, modificarse y distribuirse el software. Una biblioteca con licencia GPL, por ejemplo, puede activar obligaciones de copyleft que te obliguen a abrir el código de tu software propietario. El SDA debe exigir al desarrollador que divulgue todos los componentes de código abierto y confirme su compatibilidad con el uso previsto del cliente.

La titularidad de la PI es la cláusula que la mayoría de los clientes ojea, y aquella en la que las consecuencias de equivocarse son mayores. En mi experiencia, también es la cláusula que genera el litigio más caro.

El caso cadence v. avanti: una lección de 265 millones de dólares

En 2002, un tribunal de California concluyó que Avanti Corporation había usado código fuente robado de Cadence en un producto competidor. La indemnización alcanzó los 265 millones de dólares. El caso se cita con frecuencia en litigios de PI de software porque ilustra qué ocurre cuando se disputa la titularidad del código fuente o, peor, cuando código que nunca debería haberse incorporado a un producto acaba allí. Una cláusula de PI bien redactada no solo define quién es titular del entregable final: exige al desarrollador que garantice que no se incorporó indebidamente PI de terceros.

Los cuatro modelos de PI

Trabajo preexistente vs. trabajo a medida

La mayoría de los desarrolladores aportan herramientas, marcos y bibliotecas que construyeron antes de tu proyecto. Estos son "trabajos preexistentes" o "PI de fondo". El SDA debe identificar claramente qué trabajo preexistente se incorporará y conceder al cliente una licencia para usarlo como parte del software entregado, sin transferir la titularidad de esas herramientas subyacentes.

Para una mirada más profunda a cómo funciona la cesión de PI en los contratos individuales de desarrolladores, la guía acuerdo de cesión de PI para desarrolladores cubre la mecánica de transferir y licenciar la titularidad del código.

Doctrina del work-for-hire

En Estados Unidos, el código escrito por un empleado dentro del ámbito de su empleo es automáticamente un work-for-hire, propiedad del empleador. El código escrito por un contratista independiente *no* es automáticamente un work-for-hire: el contratista conserva los derechos de autor salvo que el contrato los ceda explícitamente. Esta distinción confunde a los clientes que asumen que son titulares del código porque pagaron por él. No lo son, sin una cláusula de cesión.

Estos tres documentos se confunden constantemente. La respuesta corta: usa un SDA para proyectos puntuales, y MSA más SOW para relaciones continuas. Cada uno tiene un papel distinto, y usar el equivocado (o confundirlos) crea lagunas de responsabilidad.

Para proyectos puntuales, un SDA independiente (como la plantilla de esta guía) cubre todo. Para colaboraciones continuas con un socio de desarrollo (donde se llevan varios proyectos a lo largo del tiempo), una estructura MSA + SOW es más eficiente. El MSA negocia el marco legal una vez; cada proyecto añade un nuevo SOW. Nuestra guía completa de Statements of Work cubre la estructura del SOW en detalle.

Conseguir un SDA firmado solía significar imprimir, escanear, enviar por correo y esperar que la versión de la otra parte coincidiera con la tuya. Ya no hay buena razón para hacerlo así. En realidad, las organizaciones que utilizan gestión de contratos automatizada reducen los tiempos de ciclo hasta en un 50 %, según la investigación del Aberdeen Group.

Qué hace que una firma electrónica sea legalmente válida

Bajo la Ley ESIGN (EE. UU.) y eIDAS (UE), una firma electrónica es legalmente válida para acuerdos comerciales cuando:

• Se aplica por alguien con intención de firmar
• Está asociada al documento específico que se firma
• Es atribuible al firmante
• El registro se almacena de forma que pueda recuperarse posteriormente

Las firmas criptográficas van más allá: cada firma se vincula matemáticamente al hash del documento. Cambia un solo carácter tras firmar y el hash cambia, haciendo la manipulación detectable de inmediato. Este no repudio hace el acuerdo defendible en los tribunales: ninguna parte puede alegar después que el documento fue alterado.

Cómo funciona el flujo de firma

La gestión documental para empresas IT suele llevar varios SDA, SOW y NDA simultáneamente. Un flujo de trabajo a propósito previene la pesadilla de control de versiones que viene con la firma por correo electrónico:

1. 1.
   Sube el SDA finalizado a un servicio de gestión de contratos
2. 2.
   Añade la dirección de correo de cada firmante y el orden de firma
3. 3.
   Cada parte recibe un enlace de firma seguro: no se requiere cuenta para firmar
4. 4.
   Se aplican las firmas; el servicio genera un certificado de finalización con marcas de tiempo, direcciones IP y el hash del documento
5. 5.
   Ambas partes reciben automáticamente el documento ejecutado
6. 6.
   La pista de auditoría se almacena de forma inmutable, accesible para futura referencia o resolución de disputas

Pagos por hitos vinculados a la firma

La función más útil de un servicio de contratos moderno no es la firma en sí, sino conectar la firma con lo que ocurre a continuación. Cuando un desarrollador entrega un hito y el cliente firma el formulario de aceptación, el disparador de pago se activa automáticamente. Sin perseguir facturas a mano, sin la confusión del "pensé que enviarías la factura por separado". Para los equipos que gestionan pagos vinculados a contratos, esto elimina la brecha entre la aceptación y la facturación.

Para un desglose completo de los precios de los planes de gestión de contratos, la página de precios de Chaindoc cubre lo que se incluye en cada nivel.