Contrato de desarrollo de software

curl -X POST https://dealroom.todo.law/api/v1/agent/contracts \
  -H "Authorization: Bearer drk_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "contractType": "SOFTWARE_DEVELOPMENT",
    "governingLaw": "SPAIN",
    "language": "es",
    "party": {
      "legalName": "Tu empresa"
    },
    "counterparty": {
      "legalName": "La otra empresa"
    },
    "terms": {
      "project-name": "<project-name>",
      "project-description": "<project-description>"
    },
    "inline": "md"
  }'

Qué es y cuándo se utiliza

El contrato de desarrollo de software se utiliza cuando un cliente encarga software a medida (una aplicación web o móvil, una plataforma o un sistema de IA) a una agencia, un estudio o un/a desarrollador/a independiente, en lugar de licenciar un producto existente. También sirve para formalizar un desarrollo que empezó de manera informal o solo con una descripción de servicios.

Además del alcance y el precio, regula los riesgos propios del software: titularidad del código, aceptación, código fuente, licencias de código abierto, uso de IA y defectos.

Quién lo firma y en qué calidad

Firman dos partes:

• El Cliente, la sociedad que encarga y paga el software.
• El/La Desarrollador/a, la sociedad o profesional que lo diseña, lo crea y lo entrega.

Las partes completan los datos del proyecto: nombre y breve descripción (ambos obligatorios) y, de forma opcional, el presupuesto total, la tarifa diaria para trabajos por tiempo y materiales, el período de garantía en meses (6 por defecto), la fecha prevista de entrega y la pila tecnológica.

Cláusulas principales

Metodología de desarrollo

Desarrollo ágil en sprints de dos semanas con un Product Owner del cliente, proyecto en cascada con fases sucesivas que se aprueban antes de pasar a la siguiente, un modelo híbrido de sprints dentro de fases de hitos, o tiempo y materiales sin alcance cerrado. La cascada da más previsibilidad al cliente; el modelo ágil y el de tiempo y materiales dan más margen al/a la desarrollador/a.

Titularidad de la propiedad intelectual

El cliente es titular de todo el resultado; o el/la desarrollador/a conserva la titularidad del código y concede al cliente una licencia exclusiva y perpetua, pudiendo reutilizar componentes genéricos; o ambas partes son cotitulares y pueden explotarlo cada una.

Estructura de pagos

Precio cerrado pagado a plazos, tiempo y materiales a las tarifas pactadas, o pagos vinculados a la finalización y aceptación de hitos definidos.

Pruebas de aceptación

Pruebas formales de aceptación con casos de prueba y derecho a rechazar lo que no se ajuste, aceptación tácita si el cliente no rechaza en un plazo, o aceptación continua en cada revisión de sprint.

Período de garantía

El/La desarrollador/a corrige defectos sin coste durante 90 días, 6 meses o 12 meses tras la aceptación. La skill describe los seis meses como el estándar del mercado.

Entrega del código fuente

Acceso completo al repositorio durante el proyecto y a su término, entrega solo del software compilado o desplegado (el código fuente lo conserva el/la desarrollador/a), o depósito del código fuente ante un agente de escrow independiente.

Gestión de cambios

Orden de cambio escrita y firmada antes de empezar cualquier trabajo, un presupuesto de cambios preaprobado (normalmente del 10 al 15 % del valor del proyecto) que se usa sin órdenes individuales, o solicitudes informales a las que sigue una evaluación de impacto formal en 5 días hábiles.

Confidencialidad

Confidencialidad mutua, obligación unilateral que protege solo la información del cliente, o confidencialidad mutua con derecho del/de la desarrollador/a a citar el proyecto en su portfolio sin revelar información confidencial.

Responsabilidad e indemnización

Responsabilidad de cada parte limitada al total de honorarios, salvo confidencialidad, dolo y fraude; el mismo límite pero con responsabilidad ilimitada del/de la desarrollador/a por infracción de propiedad intelectual; o indemnidad mutua en proporción a la culpa, con límite en el doble de los honorarios. Una cuarta opción, para software que se introduzca en el mercado de la UE, reparte la repetición conforme a la Directiva de responsabilidad por productos y se combina con un límite general.

Resolución y traspaso

Cualquiera de las partes puede resolver con 30 días de preaviso pagando el trabajo realizado; resolución solo por incumplimiento material tras un plazo de subsanación; o salida de cualquiera de las partes al completar un hito.

Componentes de código abierto

Garantía de que ningún componente impone copyleft sobre el código del cliente, con anexo de declaración; solo licencias permisivas, con consentimiento para las demás; o copyleft permitido si se mantiene separado en la arquitectura, con consentimiento específico para la AGPL en software ofrecido en red.

Desarrollo asistido por IA

IA generativa prohibida para el código entregable; herramientas de IA de una lista aprobada y declarada, con trazabilidad, revisión humana y garantía de que no se copia literalmente código de terceros sujeto a licencia; o libre elección de herramientas, asumiendo el/la desarrollador/a toda la garantía e indemnidad por infracción y aceptando el cliente que las partes generadas solo por IA pueden no estar protegidas por derechos de autor.

Las cláusulas estándar regulan además la programación segura, un jefe/a de proyecto con informes de avance, los componentes de terceros, la protección de datos y las copias de seguridad.

Qué suelen negociar las partes

El cliente suele preferir la cascada, la titularidad plena, el precio cerrado, las pruebas formales, la garantía de 12 meses, el acceso al repositorio, la confidencialidad unilateral, la responsabilidad ilimitada por infracción de propiedad intelectual, la garantía de ausencia de copyleft y la prohibición de la IA generativa. El/La desarrollador/a suele preferir tiempo y materiales, conservar la titularidad del código, la aceptación tácita, la garantía de 90 días, entregar solo el software compilado, el copyleft con segregación y el uso libre de IA.

Cuando las partes no se ponen de acuerdo, Dealroom propone las posiciones equilibradas de la skill:

• Metodología: el modelo híbrido de sprints e hitos.
• Propiedad intelectual: cotitularidad.
• Garantía: 6 meses.
• Cambios: el presupuesto de cambios preaprobado.
• Confidencialidad: mutua.
• Responsabilidad: límite en el total de honorarios, o indemnidad mutua proporcional.
• Resolución: salida al completar un hito.

Pagos, aceptación, código fuente y código abierto no tienen una opción totalmente neutral; los pagos por hitos, la aceptación continua, el escrow y las licencias permisivas son las más cercanas al punto medio. En IA, la opción de herramientas declaradas es la predeterminada y se inclina solo ligeramente hacia ambas partes.

Jurisdicciones e idiomas que admite Dealroom

Dealroom redacta este contrato conforme al Derecho de California, de Inglaterra y Gales y español, en español o en inglés.

• California: los litigios se someten a los tribunales del condado de San Francisco y las partes renuncian al jurado. La cesión respeta el artículo 2870 del Labor Code para las invenciones realizadas en el tiempo propio del/de la desarrollador/a y, si es persona física, el contrato recoge que su condición de independiente debe superar el test ABC.
• Inglaterra y Gales: la titularidad sigue la Copyright, Designs and Patents Act 1988, por lo que la cesión al cliente debe constar por escrito. La Supply of Goods and Services Act 1982 impone diligencia razonable y nunca se excluye la responsabilidad por fraude, muerte o lesiones causadas por negligencia.
• España: la titularidad se rige por la Ley de Propiedad Intelectual. Como la presunción a favor del empresario solo alcanza a los asalariados, la cesión es expresa, escrita y fija su duración y ámbito territorial; los derechos morales son irrenunciables. Los datos personales se rigen por el RGPD y la LOPDGDD, y los litigios se someten a los tribunales del domicilio social del cliente. La skill advierte de que, a julio de 2026, España no había transpuesto aún la nueva Directiva de responsabilidad por productos.

Errores frecuentes

• Dar por hecho que el código es del cliente. Sin cesión firmada, el trabajo de un profesional externo sigue siendo suyo en las tres jurisdicciones.
• Vincular la liberación del escrow o la resolución a la mera declaración de concurso. Estas cláusulas son en general ineficaces o están restringidas en las tres jurisdicciones; la skill las vincula al cese del cumplimiento o al rechazo del contrato.
• Excluir toda responsabilidad en Inglaterra y Gales. Sin la salvedad de muerte y lesiones por negligencia, la exclusión es parcialmente ineficaz.
• Tratar igual todas las licencias copyleft. La LGPL usada mediante enlace dinámico no alcanza al código propio del cliente como puede hacerlo la GPL.
• No decir nada sobre la IA. Un contrato de desarrollo de 2026 sin cláusula de IA deja sin asignar los riesgos de titularidad, infracción y confidencialidad.
• Ignorar el régimen europeo de responsabilidad por productos. El software introducido en el mercado de la UE después del 9 de diciembre de 2026 queda sujeto a una responsabilidad objetiva que el contrato no puede eliminar.