Contrato de desarrollo de software: qué debe incluir antes de firmar

Un sistema a la medida no existe cuando lo pagas: se construye durante semanas o meses, y en ese tiempo cambian las prioridades, aparecen ideas nuevas y alguien tiene que decidir qué entra y qué no. El contrato es el acuerdo que ambas partes consultan cuando eso pasa.

Por eso un buen contrato de desarrollo de software no se mide por lo largo, sino por lo concreto: qué se va a entregar, cómo se sabe que está terminado, cuánto se paga en cada momento y de quién es lo que se construyó.

Esta guía explica qué conviene dejar por escrito desde el punto de vista de quien contrata. No sustituye la revisión de un abogado: antes de firmar, que alguien de tu confianza lea el texto final.

1. Alcance: qué hace el sistema, para quién y qué queda fuera. Mejor una lista de funciones y pantallas que un párrafo general como «un sistema de ventas».
2. Etapas y entregables: qué se entrega en cada etapa y en qué ambiente (de prueba o en producción), con una fecha estimada para cada una.
3. Criterios de aceptación: cómo se revisa una entrega, cuánto tiempo tienes para revisarla y qué pasa si algo no funciona como se acordó.
4. Pagos: cuánto se paga y contra qué. Lo más sano es pagar por etapa entregada, no por meses transcurridos ni todo al inicio.
5. Cambios: cómo se pide algo nuevo a mitad del proyecto, quién lo cotiza y cuándo entra. Sin esta cláusula, cada cambio se vuelve una discusión.
6. Propiedad: de quién son el código fuente, la base de datos, los diseños y las cuentas de los servicios (servidor, dominio, correo) cuando termina el proyecto.
7. Confidencialidad y datos: qué puede ver el proveedor de tu información y de tus clientes, y qué hace con ella al terminar.
8. Garantía: durante cuánto tiempo se corrigen sin costo los errores de lo entregado, y qué cuenta como error y qué como cambio.
9. Soporte y mantenimiento: si se incluye, qué cubre, con qué tiempos de respuesta y cuánto cuesta. Muchas veces conviene un acuerdo aparte.
10. Terminación: cómo se sale del contrato, qué se entrega en ese caso y qué se paga por el trabajo hecho hasta ese día.

Es la que más se pasa por alto y la que más cuesta corregir después. Si el contrato no dice con claridad que el código fuente y la base de datos son de tu empresa, puedes terminar pagando un sistema que no puedes mover, ni modificar con otro proveedor, ni llevarte si la relación termina.

Lo que conviene que diga, por escrito:

• Que el código fuente desarrollado para tu proyecto, y sus derechos de explotación, pasan a tu empresa al pagarse cada etapa o al entregar el proyecto.
• Que recibes el código completo en un repositorio a nombre de tu empresa, no solo el sistema funcionando.
• Que la base de datos y su contenido son tuyos y puedes exportarlos cuando quieras.
• Que el servidor, el dominio y las demás cuentas de servicio están a nombre de tu empresa, o se transfieren al terminar.
• Qué piezas no son exclusivas: librerías de código abierto o herramientas del proveedor que se usan en varios proyectos. Es normal que existan; lo importante es que no te impidan operar ni cambiar de proveedor.

En Gridarco, al entregar, el código, la base de datos y las cuentas de servicio quedan a nombre de tu empresa. Si sigues trabajando con nosotros es porque te conviene, no porque dependas de nosotros.

El modelo por etapas reparte el riesgo: pagas por algo que ya puedes usar, y antes de la siguiente etapa puedes ajustar prioridades con lo que aprendiste. Es como trabajamos, y lo que explicamos en la guía de qué preparar antes de pedir una cotización.

• El alcance cabe en una línea y no dice qué queda fuera.
• Se paga la mayor parte al inicio, antes de ver nada funcionando.
• No menciona el código fuente, o dice que el proveedor «otorga una licencia de uso» sin decir hasta cuándo ni con qué límites.
• El servidor y el dominio quedan a nombre del proveedor sin plan para transferirlos.
• No hay criterios de aceptación: lo entregado está «terminado» cuando el proveedor lo dice.
• Salir del contrato cuesta más que seguir, o no dice qué recibes si sales.

Ninguna de estas señales significa mala fe; muchas veces es solo un formato genérico. Pero son puntos para pedir por escrito antes de firmar, y un buen proveedor no debería tener problema en aclararlos.