Contrato de desarrollo de software a medida
Un contrato de desarrollo de software a medida debe fijar por escrito el alcance por fases, la aceptación de cada entrega, la cesión de derechos sobre el código (la ley exige que sea por escrito), la exportación y protección de tus datos, el mantenimiento y un plan de salida.
Un contrato de desarrollo de software a medida debe dejar por escrito seis cosas: el alcance de cada fase, cómo y cuándo se entrega, cómo se acepta cada entrega, de quién son el código y los datos, qué incluye el mantenimiento y cómo se sale si cambias de proveedor. Lo que no está escrito, en un desacuerdo, se discute.
Aquí repasamos qué cláusulas conviene revisar y qué dice la Ley de Propiedad Intelectual sobre los programas de ordenador, citando su texto consolidado del BOE.
Antes de firmar: qué exigir
Un buen contrato recoge un buen planteamiento; no lo sustituye. Antes de llegar a las cláusulas, el proveedor debería poder darte por escrito:
- Una propuesta cerrada por fases, con lo que entra y lo que no en cada una.
- Un prototipo navegable de las pantallas antes de programar.
- Un calendario de entregas que puedas probar, no solo porcentajes de avance.
- Cómo usa las pruebas automáticas: la respuesta correcta es que, si una falla, el cambio no se publica.
- Cuándo restauró una copia de seguridad por última vez. Una copia que nunca se ha restaurado es una suposición.
Alcance y entregas por fases
El alcance suele ir en un anexo técnico, y es una parte que puede evitar o provocar muchas discusiones. Debe decir qué funciones incluye cada fase, qué perfiles de usuario hay, qué integraciones se hacen y qué datos se migran. Igual de importante: qué queda fuera.
Los cambios van a llegar, porque al ver el software funcionando siempre aparecen ideas. El contrato debe fijar cómo se piden: por escrito, con su precio y su plazo antes de hacerse, y con la aprobación de quien decide en tu empresa. Así un cambio no se convierte en una factura sorpresa ni en un retraso sin explicación.
Conviene también dejar claro si pagas por un resultado entregado y aceptado o por horas de dedicación. Son planteamientos distintos, con riesgos distintos, y cada uno pide cláusulas distintas.
Aceptación: cuándo se da por buena una entrega
Sin un procedimiento de aceptación, «terminado» significa cosas distintas para cada parte. Pide que el contrato recoja:
- Criterios de aceptación por fase: qué tiene que poder hacerse, con qué datos y en qué dispositivos.
- Un plazo de revisión para que tu equipo pruebe, y qué pasa si nadie responde en ese plazo.
- Una clasificación de incidencias: bloqueante (impide trabajar), grave y menor, con un plazo de corrección para cada una.
- El pago ligado a la aceptación de cada fase, no al calendario.
Propiedad del código: qué dice la ley
La Ley de Propiedad Intelectual (texto refundido aprobado por el Real Decreto Legislativo 1/1996) dedica su Título VII a los programas de ordenador. Según su artículo 95, en lo que ese título no prevé específicamente se aplican las disposiciones de la propia ley que resulten aplicables, y por eso importan también las reglas generales sobre la cesión de derechos. Estos son los artículos que más importan al encargar un desarrollo:
- Artículo 96. Protege el programa, si es original, en cualquier forma de expresión e incluye su documentación preparatoria; la documentación técnica y los manuales de uso tienen la misma protección.
- Artículo 97. Es autor la persona o grupo de personas físicas que lo crean, o la persona jurídica en los casos que la ley prevé expresamente. Cuando lo crea un trabajador asalariado en el ejercicio de sus funciones o siguiendo instrucciones del empresario, los derechos de explotación, del programa fuente y del objeto, corresponden al empresario, salvo pacto en contrario.
- Artículo 43. La cesión de derechos queda limitada a los derechos cedidos, a las modalidades de explotación expresamente previstas y al tiempo y territorio que se fijen. Si no se menciona el tiempo, se limita a cinco años; si no se menciona el territorio, al país en el que se realiza la cesión. Y si no se concretan las modalidades de explotación, la cesión se limita a la que se deduzca necesariamente del contrato y sea indispensable para cumplir su finalidad.
- Artículo 45. Toda cesión debe formalizarse por escrito.
- Artículo 99. Los derechos exclusivos de explotación incluyen hacer o autorizar la reproducción, la transformación y la distribución pública del programa. Cuando se cede el derecho de uso, se entiende, salvo prueba en contrario, que la cesión es no exclusiva e intransferible y solo para las necesidades del usuario.
- Artículo 100.4. Salvo pacto en contrario, el autor no puede oponerse a que el cesionario titular de los derechos de explotación haga o autorice versiones sucesivas del programa o programas derivados. Importa si mañana quieres que otro equipo lo haga evolucionar; que puedas apoyarte en esa regla depende de que el contrato te ceda esos derechos.
La regla del artículo 97.4 que da los derechos al empresario habla de trabajadores asalariados. Si encargas el programa a una empresa externa, no conviene dar por hecho que funciona igual: qué derechos recibes dependerá de lo que se pacte por escrito y de cómo se interprete ese contrato, y es un terreno en el que lo prudente es no dejar nada abierto. Por eso el contrato debería concretar: qué derechos se ceden (uso, modificación, distribución), si la cesión es exclusiva, por cuánto tiempo y en qué territorio, cuándo se entrega el código fuente con su documentación y qué ocurre con las piezas que el proveedor ya tenía antes de tu proyecto o con los componentes de terceros, que tienen sus propias licencias.
Caben varios modelos: la cesión de los derechos sobre todo lo desarrollado, o una licencia de uso sobre un núcleo que el proveedor ya tenía, junto con la cesión de lo hecho para ti. Si el proveedor parte de una base propia, pide por escrito qué es tuyo y qué es licencia. No es un problema si lo sabes y está escrito; sí lo es si lo descubres el día que quieres cambiar de proveedor.
Tus datos: propiedad, exportación y protección
Con el código puede haber matices; con los datos, no debería haberlos. Que clientes, facturas, documentos e histórico son de tu empresa conviene que el contrato lo diga expresamente, junto con cómo se exportan: en formatos abiertos, completos y sin depender de la buena voluntad del proveedor.
Si el proveedor va a tratar datos personales por tu cuenta, como los de tus clientes o empleados, necesitáis además un contrato de encargado del tratamiento: el artículo 28 del Reglamento General de Protección de Datos exige que ese tratamiento se rija por un contrato u otro acto jurídico que vincule al encargado. La Agencia Española de Protección de Datos publica unas directrices para redactarlo, con cláusulas de ejemplo que incluyen qué hace el encargado al terminar: suprimir o devolver los datos, según se pacte, y borrar las copias que tenga.
Mantenimiento y soporte
El día que se entrega el sistema empieza su vida útil, no termina el proyecto. La cláusula de mantenimiento debe separar tres cosas:
- Correctivo y seguridad: corrección de errores, actualizaciones de seguridad y compatibilidad con navegadores y dispositivos.
- Operación: alojamiento, copias de seguridad fuera del servidor principal y restauraciones de prueba.
- Evolutivo: funciones nuevas, que se presupuestan aparte.
Y para cada nivel de incidencia, un tiempo de respuesta y otro de solución. Añade también cómo se publican las versiones nuevas: en los sistemas que operamos, una comprobación automática impide publicar si un local está cobrando, y antes de sustituir la versión en marcha se comprueba que la nueva arranca de verdad.
Salida y portabilidad
Es una cláusula fácil de aplazar al principio y difícil de negociar cuando ya hace falta. Un buen plan de salida recoge:
- La exportación completa de tus datos en un formato abierto, en un plazo concreto.
- La entrega del código fuente y la documentación que te correspondan según la cesión.
- Una colaboración razonable en la transición a otro equipo, con su precio.
- La supresión o devolución de los datos personales, como fija el contrato de encargado.
- Si el sistema es crítico, un depósito del código fuente ante un tercero para el caso de que el proveedor desaparezca.
Resumen de cláusulas
| Cláusula | Qué debe decir | Señal de alarma |
|---|---|---|
| Alcance | Funciones por fase y lo que queda fuera | «El sistema completo» sin anexo |
| Cambios | Por escrito, con precio y plazo antes de hacerse | Cambios verbales que aparecen en la factura |
| Aceptación | Criterios, plazo de revisión y tipos de incidencia | Se da por aceptado al entregar |
| Propiedad | Derechos cedidos, tiempo, territorio y código fuente | Nada escrito sobre la cesión |
| Datos | Tuyos, exportables, con contrato de encargado | Exportar solo como servicio de pago |
| Mantenimiento | Qué incluye y tiempos de respuesta | «Soporte» sin más detalle |
| Salida | Datos, código, transición y plazos | No se menciona |
Así planteamos nosotros los proyectos: propuesta cerrada por fases, prototipo navegable antes de programar, entregas con pruebas automáticas y exportación de datos como parte de la base técnica. Lo contamos en desarrollo de software a medida. Si quieres ver cómo se reparte el trabajo en el tiempo, lee las fases de un proyecto de software, y si estás comparando ofertas, el precio de un software a medida.
Fuentes consultadas
Comprobadas el 26 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
Preguntas frecuentes
¿Quién es el dueño del código si el contrato no dice nada?
Depende de cómo se interprete ese contrato, y conviene no llegar a esa situación. La ley exige que toda cesión se formalice por escrito (artículo 45 de la Ley de Propiedad Intelectual) y, si no se concretan las modalidades de explotación, la limita a la que se deduzca necesariamente del contrato y sea indispensable para cumplir su finalidad (artículo 43). Por eso lo prudente es fijar por escrito, antes de empezar, qué derechos se ceden y qué queda como licencia.
¿Es mejor un contrato a precio cerrado o por horas?
Un precio cerrado por fase reparte el riesgo: el proveedor se compromete con un alcance concreto y tú sabes qué pagas por cada entrega. Por horas encaja en mantenimiento y evolución, siempre con una estimación y un tope.
¿Qué es el depósito del código fuente?
Es dejar una copia del código y su documentación en manos de un tercero, que te la entrega si el proveedor desaparece o incumple lo pactado. Tiene sentido cuando el sistema es crítico y el código no se te entrega directamente.
¿Necesito un contrato de encargado del tratamiento con mi proveedor de software?
Si el proveedor va a tratar datos personales por tu cuenta, sí: el artículo 28 del RGPD exige que ese tratamiento se rija por un contrato u otro acto jurídico que vincule al encargado. La AEPD publica unas directrices con cláusulas de ejemplo que sirven de punto de partida.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.