Un contrato de desarrollo de software debe fijar qué se construye, en qué fases y a qué precio. También cómo se acepta cada entrega y de quién son el código y los datos. Y qué fallos se corrigen después, o qué pasa si una parte quiere terminar. La cesión de derechos sobre el código, además, tiene que constar por escrito.
Qué tipo de contrato es.
Encargar un desarrollo es, en términos del Código Civil, un arrendamiento de obra o de servicios. Una parte se obliga a ejecutar una obra o a prestar un servicio por precio cierto. Lo que se pacta encima de esa base es lo que de verdad protege a las dos partes.
Esta guía sirve para preparar la conversación con tu abogado. No es un modelo de contrato. Cada proyecto tiene sus riesgos, y conviene que un profesional revise el texto final.

Objeto y alcance.
El objeto es lo que se va a construir. Cuanto más concreto, menos discusiones después.
Lo más práctico es adjuntar un documento de alcance con las funciones de la primera versión, las plataformas y las integraciones. Lo que no está en ese documento no entra en el precio. Si aparece algo nuevo, se presupuesta aparte.
Ese documento también protege al proveedor. Le permite decir con claridad qué es un cambio y qué es un fallo. Para prepararlo, mira cómo preparar el encargo de un software.
Fases, plazos y pagos.
Dividir el proyecto en fases reduce el riesgo para las dos partes. Cada fase tiene un resultado que se puede ver y un precio.
Conviene ligar los pagos a esas fases. Una forma de equilibrar el riesgo es pagar una parte al empezar y el resto al aceptar cada entrega. Lo importante es que el contrato diga qué se paga, cuándo y contra qué entrega.
Los plazos dependen de las dos partes. Si tu empresa tiene que aportar contenidos o accesos, el contrato debería decir cuándo. Así un retraso en tu lado no se convierte en un incumplimiento del proveedor.

Entrega y aceptación.
Una entrega no es solo «ya está». El contrato debería decir qué se entrega, cómo se prueba y cuánto tiempo tienes para revisarlo.
Pacta también qué pasa si encuentras fallos durante la revisión. Lo razonable es que el proveedor los corrija y vuelva a entregar antes de considerar aceptada la fase.
La entrega debe incluir el código y la documentación. La ley protege ambos como parte del programa.
Propiedad del código.
Es una cláusula que cuesta mucho arreglar después si falta. La cesión de los derechos de explotación debe hacerse por escrito. Si el contrato no dice el plazo, la cesión se limita a cinco años.
Si quieres que nadie más pueda explotar el código, pide la cesión en exclusiva. Esa cesión permite explotar la obra con exclusión de otras personas, incluido el propio cedente.
Deja claro también qué partes no se ceden, como librerías de terceros o piezas que el proveedor reutiliza. Sobre las librerías, mira qué licencias de código abierto conviene revisar. Lo explicamos con detalle en de quién es el código fuente.
Datos personales y confidencialidad.
Si el proveedor va a acceder a datos personales de tus clientes, necesitas un contrato de encargado del tratamiento. Puede ir como anexo del contrato principal.
Ese contrato debe decir qué pasa con los datos al terminar. El RGPD prevé que el encargado los suprima o los devuelva, a elección del responsable. Pide también una exportación completa en un formato que puedas usar.
La confidencialidad cubre lo que no son datos personales: tu negocio, tus procesos y tus planes. Conviene que esa obligación dure más allá del contrato.
Garantía, soporte y mantenimiento.
Separa tres cosas que a menudo se mezclan. La garantía cubre los fallos de origen, los que vienen de cómo se programó. El soporte resuelve dudas e incidencias. El mantenimiento adapta la aplicación a cambios externos y se contrata aparte.
El contrato debe decir cuánto dura la garantía y qué queda fuera. Por ejemplo, los fallos causados por un cambio de un tercero o por modificaciones que haga otra persona.
Cómo terminar el contrato.
Ningún proyecto empieza pensando en terminar mal, pero conviene preverlo. El contrato debería decir cómo se puede resolver, con qué preaviso y qué se paga por el trabajo hecho.
Lo más importante es qué te llevas. Si un día tienes que retomar un proyecto a medias, lee cómo continuar un proyecto abandonado. El código entregado hasta ese momento, la documentación, las cuentas y los datos. Si eso está claro, otro proveedor puede continuar.
En OverFuture cada fase tiene su presupuesto cerrado. En la mayoría de proyectos, el código, los datos y las cuentas quedan a tu nombre, según contrato. Durante el primer año tras la entrega corregimos sin coste los fallos de origen de nuestro desarrollo. Los textos legales los redacta tu asesor y nosotros los integramos.
Si estás comparando proveedores, sigue nuestra guía para elegir empresa de desarrollo de software. Y si todavía no tienes claro el tipo de proveedor, lee freelance o agencia para tu software. Puedes ver cómo trabajamos en desarrollo de software a medida.
Preguntas frecuentes.
Sí. Basta un documento corto, pero la cesión del código tiene que estar por escrito.
El precio cerrado por fase da previsibilidad. Por horas encaja cuando el alcance no se puede definir. Lo comparamos en precio del software a medida.
Puede proponerlo cualquiera de las partes. Lo importante es que lo revise un abogado antes de firmar.
Depende de quién cause el retraso. Por eso conviene que el contrato diga qué debe aportar cada parte y cuándo.





