Qué debe incluir un contrato de desarrollo de software

Un contrato de desarrollo no sirve para el proyecto que sale bien. Para ese sirve cualquier cosa, incluido un correo. Sirve para el que se tuerce: el que se retrasa, el que cambia de alcance a mitad, el que se detiene, o aquel en el que las dos partes recuerdan de forma distinta lo que se acordó.

Esto está escrito desde el lado del proveedor, para el que contrata. Varias de las cláusulas de abajo nos convienen menos a nosotros que a usted, y las recomendamos igual porque un proyecto con reglas claras es más barato para todos que uno donde cada desacuerdo hay que negociarlo desde cero.

No es asesoría legal. Es la lista de lo que la experiencia dice que hay que cubrir. La redacción concreta y su encaje con la legislación ecuatoriana los ve un abogado.

1. De quién es el código

La primera y la que más veces está mal.

Debe decir explícitamente que la propiedad intelectual del código desarrollado a medida es del cliente, desde cuándo —normalmente contra pago— y qué incluye la cesión. Si el proveedor incorpora componentes propios reutilizables o librerías de terceros, eso no se cede: se licencia. Y esa licencia tiene que estar escrita, porque es la diferencia entre poder cambiar de proveedor y no poder.

La prueba de si la cláusula sirve: si mañana quiere que otro equipo continúe el trabajo, ¿el contrato se lo permite sin pedir permiso a nadie?

2. Qué entra y, sobre todo, qué no entra

Un alcance se define por sus dos caras. Un documento que solo enumera lo que se va a construir deja toda la zona gris a interpretación, y la zona gris siempre se descubre tarde.

Anexe el alcance como documento propio, con los procesos cubiertos, y una lista explícita de exclusiones. «No incluye migración de datos históricos anteriores a 2020», «no incluye integración con facturación electrónica», «no incluye capacitación presencial fuera de Guayaquil». Escribir exclusiones se siente hostil al firmar y ahorra la discusión más cara del proyecto.

3. Cómo se cambia el alcance

Va a cambiar. La pregunta no es si, sino con qué procedimiento.

Debe definir quién puede solicitar un cambio, quién lo aprueba por cada lado, en qué plazo se valora su impacto en costo y fecha, y qué pasa mientras tanto. Sin esto, los cambios entran por conversación, nadie los cuantifica, y al final del proyecto hay un desfase de plazo que cada parte atribuye a la otra con razones igual de buenas.

4. Qué significa «terminado»

Criterios de aceptación por entregable, escritos antes de construirlo. Quién prueba, contra qué, en cuánto tiempo, y qué pasa si nadie prueba dentro de ese plazo —la aceptación tácita por silencio es razonable si el plazo es razonable, y tiene que estar dicha.

Sin esto, «terminado» es una opinión, y suele haber dos.

5. Qué pasa cuando el retraso es del cliente

La cláusula que ningún cliente quiere y que evita la mayoría de los conflictos de plazo.

Un proyecto depende de cosas que el proveedor no controla: accesos a sistemas, disponibilidad de una persona que decide, datos para migrar, un ambiente de pruebas del ERP. Cuando eso llega tarde, el proyecto se retrasa, y sin cláusula el retraso queda contablemente en la cuenta del proveedor.

Defina qué dependencias son del cliente, con qué plazo, y qué efecto tiene el incumplimiento sobre el cronograma. Es simétrico: también debe decir qué pasa cuando el que se retrasa es el proveedor.

6. Pagos atados a hitos, no al calendario

Pagar por meses transcurridos alinea mal los incentivos. Pagar contra hitos verificables —definidos en el punto 4— los alinea bien.

Y una recomendación práctica: que ningún hito represente una fracción tan grande del total que su discusión bloquee el proyecto entero.

7. Garantía y mantenimiento no son lo mismo

Garantía es corregir sin costo lo que no funciona como se acordó, durante un período definido después de la entrega. Mantenimiento es todo lo demás: cambios, mejoras, adaptaciones a normativa nueva.

Si el contrato no traza esa frontera con ejemplos, se discute cada vez, y se discute en el peor momento —cuando algo falla en producción y las dos partes están tensas.

8. Qué pasa si el proyecto se detiene

Cualquiera de las dos partes puede necesitar salir: presupuesto, prioridades, una fusión, un cambio de dirección.

El contrato debe decir con cuánto preaviso, qué se paga de lo ejecutado, y —lo más importante— qué se entrega en ese momento. Si el proyecto se construye por fases que terminan en producción, lo entregado hasta ahí le sigue sirviendo. Si se construye como un bloque monolítico que solo funciona al final, salir a mitad significa que no se lleva nada, y eso también hay que saberlo al firmar.

9. Qué incluye la entrega, en concreto

No «el sistema». Enumérelo:

• El repositorio completo, con su historial
• La documentación de despliegue y de operación
• Las credenciales de todos los servicios
• Los datos migrados y el procedimiento de migración
• Un respaldo restaurado al menos una vez, verificado

Ese último punto es el que más se omite y el único que demuestra que los respaldos existen de verdad.

10. De quién son las cuentas y la infraestructura

La cláusula que casi nadie escribe y que produce los conflictos más feos.

El dominio, el hosting, la cuenta de nube, el certificado, el repositorio, la cuenta de la tienda de aplicaciones: ¿a nombre de quién están? Registrarlo todo a nombre del proveedor «para simplificar la gestión» es cómodo durante el proyecto y es un problema de propiedad el día que la relación termina, especialmente si termina mal.

A nombre del cliente, con el proveedor como usuario con permisos. Siempre.

Confidencialidad y datos personales

Aparte de las diez, dos que son obligatorias y no opcionales.

Confidencialidad recíproca: usted le abre su operación a un tercero, y ese tercero le muestra su forma de trabajar. Y si el sistema trata datos personales —casi todos lo hacen—, el contrato tiene que decir quién es responsable, quién es encargado del tratamiento, qué medidas de seguridad se aplican y qué pasa con esos datos al terminar. En Ecuador esto tiene marco legal propio y es materia de abogado, no de plantilla descargada.

La prueba de si su contrato sirve

Léalo imaginando que la relación se rompió y que ninguna de las dos partes está de buena fe. Si en ese escenario el documento responde quién es dueño de qué, qué se debe, qué se entrega y cómo se sale, sirve.

Si solo funciona asumiendo que ambas partes se entienden, entonces no es un contrato. Es un acta de la reunión en la que se cayeron bien.