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

La mayoría de los proyectos de software no fracasan porque los desarrolladores sean malos programando. Fracasan porque nadie escribió qué significa "terminado". El Informe CHAOS de Standish Group sitúa la tasa de éxito de los proyectos de software en apenas un 31 % — y los desacuerdos sobre el alcance, la propiedad intelectual poco clara y los términos de pago disputados son los culpables más comunes.

Un contrato de desarrollo de software soluciona 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 lo posee, cuánto cuesta y qué ocurre cuando algo sale mal. Sin uno, confía en la buena fe y la memoria — y los tribunales no aceptan ninguna de las dos.

Esta guía lo cubre todo: cuándo necesita un contrato de desarrollo de software, los cuatro tipos de contrato y cuándo usar cada uno, cada cláusula que realmente importa, y una plantilla descargable gratuita que puede personalizar para su proyecto. Si ya conoce lo básico y quiere ir directamente a la plantilla, avance hasta la sección de la plantilla. De lo contrario, el contexto importa — especialmente la sección de PI, que es donde la mayoría de los contratos fracasan en silencio. Para una visión más amplia de cómo difieren los acuerdos de los contratos, nuestra guía de contrato vs. acuerdo cubre las distinciones legales que vale la pena conocer.

Un contrato de desarrollo de software (SDA, por sus siglas en inglés) es un contrato jurídicamente vinculante entre un cliente y un desarrollador de software o empresa de desarrollo. Define el alcance del trabajo, la estructura de pagos, el cronograma de entrega, la propiedad intelectual, los términos de confidencialidad y qué ocurre si alguna de las partes necesita salir del acuerdo.

El SDA no es una propuesta, un resumen del proyecto ni un hilo de Slack confirmando el trabajo. 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á si hay una disputa — y el documento que leerá un tribunal si llega a eso.

Qué cubre un SDA

Un contrato de desarrollo de software correctamente redactado abordará:

• Alcance del trabajo — qué construirá el desarrollador, con suficiente especificidad para que un tercero pueda evaluar su finalización
• Entregables e hitos — qué se entrega, en qué forma y para cuándo
• Términos de pago — tarifa total, cronograma de pagos y qué desencadena cada pago
• Propiedad intelectual — quién posee el código después de escribirlo
• Confidencialidad — qué información propietaria cada parte debe mantener privada
• Pruebas de aceptación — cómo el cliente evalúa 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 finalizar el acuerdo y qué ocurre con el trabajo ya completado

Algunos clientes confunden el SDA con un Statement of Work (SOW). Hay solapamiento, pero no son lo mismo — y la distinción importa. La relación entre un MSA y un SOW explica cómo funcionan juntos estos documentos en compromisos a largo plazo.

Respuesta corta: cada vez que pague a alguien para que construya software, o le paguen a usted por construirlo.

El contrato importa tanto si contrata a un freelancer independiente para un proyecto de dos semanas como si trabaja con una agencia de 20 personas para construir un producto durante 12 meses. La escala cambia; la necesidad de términos por escrito no.

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

• Subcontrata el desarrollo de software — especialmente a equipos offshore o remotos donde las diferencias de jurisdicción complican los acuerdos informales
• Se construye software a medida — cuanto más personalizado sea el trabajo, más necesita documentación explícita sobre la propiedad intelectual
• Existen múltiples fases de desarrollo — los pagos basados en hitos requieren criterios de aceptación por escrito para desencadenar cada fase
• Se involucran datos o sistemas sensibles — cualquier proyecto que toque datos de clientes necesita cláusulas de confidencialidad y seguridad
• Construye sobre frameworks propietarios — el código preexistente que se incorpora a entregables personalizados crea preguntas complicadas sobre propiedad sin un acuerdo claro
• Trabaja a través de fronteras — la ley aplicable y la jurisdicción deben nombrarse cuando el desarrollador y el cliente están en países diferentes

La única situación en la que podría arreglárselas sin un SDA completo: trabajos muy cortos y de bajo valor gobernados por un acuerdo de servicios maestros (MSA) integral que ya cubre todos los términos relevantes. Pero incluso entonces, la mayoría de abogados le dirían que haga el papeleo.

No existe una única plantilla de SDA que se adapte a cada compromiso. La estructura del contrato debe coincidir con cómo se presupuesta y define el proyecto — y elegir la estructura equivocada crea incentivos que trabajan en contra de 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 etapas iniciales, o cualquier situación donde el alcance completo no pueda definirse de antemano. El cliente paga por las horas reales trabajadas a tarifas acordadas. Obtiene flexibilidad; la contrapartida es la incertidumbre de costes. Los límites presupuestarios y los techos mensuales ayudan a gestionar ese riesgo.

Acuerdos de equipo dedicado

Para empresas que necesitan un equipo de ingeniería remoto consistente — en lugar de una entrega de proyecto puntual — un acuerdo de equipo dedicado establece los términos de una relación continua. La gestión de contratos para empresas de TI típicamente involucra este modelo cuando trabaja con socios de subcontratación.

Estructura MSA + SOW

Los compromisos más grandes a menudo separan el marco legal maestro (MSA) de los términos específicos del proyecto (SOW). El MSA cubre la propiedad intelectual, confidencialidad, responsabilidad y resolución de disputas una vez; cada SOW cubre los entregables específicos, el cronograma y el pago de un proyecto particular.

No todas las cláusulas tienen el mismo peso. Estas son las que, cuando faltan o son vagas, causan disputas en el mundo real.

1. Alcance del trabajo y entregables

Describa qué se construye con suficiente detalle para que alguien no involucrado en el proyecto pueda evaluar si fue entregado. Los requisitos funcionales, las especificaciones técnicas, las plataformas compatibles y los puntos de referencia de rendimiento pertenecen aquí. Nombre explícitamente qué queda fuera del alcance.

El alcance vago es la fuente más común de disputas de software. "Construir un sitio web" no es un alcance. "Construir una aplicación React/Next.js responsiva con las funciones listadas en el Anexo A, superando puntuaciones de rendimiento Lighthouse de 90+ en móvil" sí lo es.

2. Términos de pago y cronograma de hitos

Liste cada pago: cantidad, evento desencadenante y método de pago. Los pagos basados en hitos deben estar vinculados a entregables aceptados, no solo a fechas del calendario. Defina la moneda, el cronograma de pago (Net-15 o Net-30 es estándar) y la penalización por pago tardío.

3. Propiedad intelectual

Esta es la cláusula que la mayoría de los clientes lee demasiado rápido. ¿Quién posee el código personalizado? ¿Quién posee cualquier código preexistente que el desarrollador incorpore? ¿Se cubre el software de código abierto? La sección de PI del SDA determina quién puede usar, modificar, vender o licenciar el software después de la entrega. Si se equivoca aquí, las consecuencias son costosas — vea 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 comercial propietaria; el cliente no puede divulgar los procesos o herramientas propietarias del desarrollador. Para términos de NDA más robustos en un acuerdo independiente, vale la pena leer la guía de NDA para contratistas de empresas de software junto con esta.

5. Pruebas de aceptación

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

6. Garantías

El desarrollador debe garantizar que el software funcionará según lo especificado, que el código es original (o correctamente licenciado), y que la entrega no infringirá los derechos de PI de terceros. Un período de garantía para correcciones de errores post-entrega — típicamente 30–90 días — protege al cliente de defectos descubiertos después del lanzamiento.

7. Condiciones de terminación

Cualquiera de las partes debería poder salir con un aviso razonable. Defina el período de aviso (30 días es estándar), qué ocurre con el trabajo en curso, y cómo se calcula el pago final en una terminación anticipada. Una cláusula de terminación por causa (que cubra incumplimiento material, insolvencia o falta de pago) debe ser separada de la terminación por conveniencia.

8. Ley aplicable y jurisdicción

Nombre el país y el estado/región cuya ley rige el acuerdo. Cuando el desarrollador y el cliente están en países diferentes, esta cláusula decide qué tribunales manejarían una disputa. No la omita porque parezca formal — es una de las cláusulas más importantes prácticamente en un compromiso transfronterizo.

Use esta plantilla como base para su acuerdo. Reemplace todos los campos entre corchetes con sus términos específicos. Para proyectos complejos, contrate a un abogado de software para revisar la versión final — especialmente las secciones de PI y garantías.

Para empresas de TI que gestionan contratos con múltiples socios de desarrollo, centralizar todos sus SDAs 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í es cómo abordar cada uno sin dejar vacíos que causen disputas más tarde.

Paso 1: Defina el alcance antes de tocar el contrato

No abra la plantilla hasta que haya documentado qué necesita hacer realmente el software. Requisitos funcionales, restricciones técnicas, plataformas compatibles, dependencias de integración — todo ello. La sección de alcance del SDA es tan buena como el documento de especificación que hay detrás.

Para proyectos complejos, adjunte la especificación completa como Anexo A y referenciela desde la cláusula de alcance. Esto mantiene el contrato principal legible mientras asegura que el detalle técnico completo esté legalmente adjunto.

Paso 2: Construya el cronograma de hitos

Trabaje hacia atrás desde la fecha de entrega. Divida el proyecto en fases — descubrimiento, diseño, desarrollo, pruebas, despliegue — y asigne un monto 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.

Advertencia justa: esto lleva más tiempo del que la mayoría de las partes esperan, especialmente en primeros compromisos. Presupueste 1-2 horas con ambas partes presentes para definir bien los hitos y los pagos.

Paso 3: Aborde la propiedad intelectual explícitamente

Lea la Sección 3 cuidadosamente y complete todos los espacios en blanco. Si el desarrollador está usando frameworks o herramientas propietarias que construyó antes de este proyecto, listelos en la exclusión de trabajo preexistente. Si está usando bibliotecas de código abierto, nombre las licencias.

La cesión de trabajo personalizado (Sección 3.1) es típicamente la cláusula más importante para los clientes: es lo que transfiere la propiedad del código entregado del desarrollador a usted. No la deje vaga.

Paso 4: Establezca la ventana de revisión y los criterios

Decida la ventana de revisión antes de completarla. Diez días hábiles es común. Dos semanas dan a los clientes ocupados suficiente tiempo para probar realmente el entregable; cualquier período más corto tiende a generar disputas cuando los revisores están viajando u ocupados.

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

Paso 5: Elija la ley aplicable deliberadamente

Para proyectos nacionales, use 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 común para contratos tecnológicos basados en EE. UU.; la ley inglesa se usa frecuentemente para acuerdos tecnológicos internacionales. Sea lo que sea que elija, ambas partes deben acordarlo explícitamente — no deje esto en blanco.

Paso 6: Firme con una firma electrónica 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 marca de tiempo son mucho más difíciles de repudiar. Según la ESIGN Act y UETA en Estados Unidos, y la eIDAS en la Unión Europea, las firmas electrónicas tienen plena fuerza legal para acuerdos comerciales. La plataforma de firma debe vincular cada firma al hash criptográfico del documento — de modo que cualquier alteración posterior a la firma sea inmediatamente detectable.

La mayoría de las plantillas cubren lo básico. Estas son las cláusulas que faltan en los acuerdos baratos o redactados rápidamente — y tienden a importar más cuando algo sale mal.

Pruebas de aceptación con criterios de aprobación/rechazo

La Sección 5 en la plantilla anterior define *cuándo* y *cómo* el cliente revisa los entregables. Lo que la mayoría de los acuerdos omiten: los criterios reales para aprobar. Sin puntos de referencia medibles de aprobación/rechazo, la aceptación se convierte en una negociación. El cliente siempre puede argumentar que el software no es "suficientemente bueno". Escriba criterios objetivos en el Anexo A antes de que comience el desarrollo.

Depósito en escrow del código fuente

Si su negocio depende del software a medida y el desarrollador cierra, necesita acceso al código fuente. Una cláusula de escrow de código fuente requiere que el desarrollador deposite el código fuente con un agente de escrow neutral. Si el desarrollador cesa operaciones o incumple materialmente el acuerdo, el escrow libera el código al cliente. La mayoría de los clientes nunca piensan en pedir esto — hasta que lo necesitan.

Período de responsabilidad post-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, ¿el desarrollador sigue siendo responsable? Defina el período de garantía y la ventana de responsabilidad post-garantía explícitamente. Después del período de garantía, la única obligación del desarrollador es típicamente abordar los defectos que causó — no errores introducidos por modificaciones del cliente.

Proceso de control de cambios

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

Cumplimiento de licencias de código abierto

La Linux Foundation reporta que el 92 % del software comercial contiene componentes de código abierto. La licencia de cada componente impone condiciones sobre cómo se puede usar, modificar y distribuir el software. Una biblioteca licenciada bajo GPL, por ejemplo, puede desencadenar obligaciones de copyleft que lo obliguen a abrir el código de su software propietario. El SDA debe requerir que el desarrollador divulgue todos los componentes de código abierto y confirme su compatibilidad con el uso previsto por el cliente.

La propiedad intelectual es la cláusula que la mayoría de los clientes lee por encima — y la que tiene las consecuencias más graves si se equivoca.

El caso Cadence v. Avanti: una lección de $265M

En 2002, un tribunal de California encontró que Avanti Corporation había usado código fuente robado de Cadence en un producto competidor. La compensación por daños alcanzó los $265M. El caso se cita frecuentemente en litigios de PI de software porque ilustra qué ocurre cuando la propiedad del código fuente se disputa o, peor aún, cuando código que nunca debería haberse incorporado a un producto termina allí. Una cláusula de PI bien redactada no solo define quién posee el entregable final — requiere que el desarrollador garantice que no se incorporó indebidamente PI de terceros.

Los cuatro modelos de PI

Trabajo preexistente vs. trabajo personalizado

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

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

Doctrina de trabajo por encargo

En Estados Unidos, el código escrito por un empleado en el ámbito de su empleo es automáticamente un trabajo por encargo, propiedad del empleador. El código escrito por un contratista independiente *no* es automáticamente un trabajo por encargo — el contratista retiene los derechos de autor a menos que el acuerdo lo ceda explícitamente. Esta distinción sorprende a los clientes que asumen que poseen el código porque lo pagaron. No lo poseen, sin una cláusula de cesión.

Estos tres documentos se confunden constantemente. Cada uno tiene un rol distinto, y usar el equivocado — o confundirlos — crea vacíos de responsabilidad.

Para proyectos puntuales, un SDA independiente (como la plantilla de esta guía) lo cubre todo. Para compromisos continuos con un socio de desarrollo — donde ejecuta múltiples 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.

Obtener un SDA firmado solía significar imprimir, escanear, enviar por correo electrónico y esperar que la versión de la otra parte coincida con la suya. Ya no hay buena razón para hacerlo de esa manera.

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

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

• Es aplicada por alguien con intención de firmar
• Está asociada con el documento específico que se firma
• Es capaz de atribuirse al firmante
• El registro se almacena en una forma que puede recuperarse más tarde

Las firmas criptográficas van más allá: cada firma está matemáticamente vinculada al hash del documento. Cambie un solo carácter después de firmar, y el hash cambia, haciendo la manipulación inmediatamente detectable. Esta no repudiación hace que el acuerdo sea defendible en tribunal — ninguna de las partes puede posteriormente afirmar que el documento fue alterado.

Cómo funciona el flujo de firma

La gestión documental para empresas de TI típicamente gestiona múltiples SDAs, SOWs y NDAs simultáneamente. Un flujo de trabajo especializado previene la pesadilla de control de versiones que viene con la firma basada en correo electrónico:

1. 1.
   Suba el SDA finalizado a una plataforma de gestión de contratos
2. 2.
   Añada la dirección de correo electrónico 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; la plataforma 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 completamente ejecutado
6. 6.
   El registro de auditoría se almacena de forma inmutable, accesible para referencia futura o resolución de disputas

Pagos por hitos vinculados a la firma

La característica más útil en una plataforma de contratos moderna no es la firma en sí — es conectar la firma con lo que ocurre después. Cuando un desarrollador entrega un hito y el cliente firma el formulario de aceptación, el desencadenante de pago se activa automáticamente. No más persecución manual de facturas, ni confusión de "pensé que enviarías la factura por separado". Para 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 planes de gestión de contratos, la página de precios de Chaindoc cubre lo que se incluye en cada nivel.