Contrato de desarrollo de software: qué debe estar por escrito

La mayoría de los conflictos entre una empresa y su proveedor de software no empiezan en el código. Empiezan en una frase que nadie escribió. ¿Qué era “terminado”? ¿Quién paga el cambio que surgió a mitad de camino? ¿De quién es el repositorio? Cuando el proyecto va bien, estas preguntas no aparecen. Cuando se retrasa, se convierten en todo el proyecto.

El contrato es el único lugar donde estas respuestas quedan registradas antes del problema. En esta guía enumero lo que debe estar por escrito en un contrato de desarrollo de software, del alcance al código fuente, junto con lo que ya dice la ley brasileña. No es un dictamen jurídico: es la lista de quien ha visto muchos proyectos empezar y terminar.

Por qué el contrato estándar del proveedor suele protegerlo solo a él

Todo proveedor tiene un modelo de contrato. Es normal. Lo que debes entender es que ese modelo se redactó para reducir el riesgo de quien lo escribió. Cláusulas de alcance vagas, plazo “estimado”, código que solo se entrega al final y licencia de uso en lugar de titularidad son comunes.

Nada de esto es ilegal. Pero todo traslada el riesgo a tu lado. Y sueles darte cuenta solo cuando quieres cambiar de equipo, como contamos en el artículo sobre el freelancer que desapareció con el proyecto. Leer el contrato con la lista de abajo en la mano lleva una hora y evita meses de problemas.

Las 9 cláusulas que debe tener el contrato

1. Alcance en entregables, no en horas

El alcance debe decir qué podrá hacer el usuario en el sistema: registrar un pedido, aprobar un pago, emitir un informe. “Desarrollo de plataforma web” no es alcance. Adjunta al contrato un anexo con las pantallas, los perfiles de acceso y las integraciones (pasarela de pago, ERP, WhatsApp). Lo que no está en el anexo no está en el precio, y eso vale para ambas partes.

2. Plazo por escrito, con hitos

Un plazo “estimado” no es un plazo. Pide una fecha final e hitos intermedios, cada uno con una entrega que puedas abrir y probar. Escribe también qué pasa si el plazo se excede por culpa del proveedor: descuento, multa o derecho a rescindir sin pagar la cuota siguiente.

3. Precio y pagos ligados a entregas

Pagar por hito protege a quien contrata. Pagas cuando recibes algo que funciona, no cuando pasa un mes. Desconfía de contratos con la mayor parte del importe por adelantado y de reajustes sin un índice definido.

4. Regla para cambios de alcance

Todo proyecto cambia. El problema no es cambiar, es no tener una regla. El contrato debe decir cómo se solicita un cambio, quién lo aprueba, cómo se calcula el impacto en precio y plazo, y que nada nuevo empieza sin aprobación por escrito. Una alternativa mejor es cambiar una función por otra del mismo tamaño, sin tocar la fecha. Explicamos esta lógica en recortar alcance para llegar a la fecha.

5. Criterio de aceptación

¿Qué significa “entregado”? El contrato debe definir un período de pruebas después de cada entrega, qué cuenta como defecto y el plazo para corregirlo. Sin eso, el proveedor da por entregado el día en que publica, y tú descubres los errores por tu cuenta.

6. Titularidad del código, los archivos y los accesos

Esta es la cláusula más importante. La Ley de Software brasileña (Ley n.º 9.609/1998) dice, en su artículo 4, que, “salvo pacto en contrario”, los derechos sobre el programa desarrollado durante el contrato y para ese fin pertenecen al contratante. Parece resuelto, pero la salvedad es justamente el punto: basta una cláusula en el contrato del proveedor que diga que él conserva los derechos y tú recibes solo una licencia de uso.

Y esos derechos duran mucho. La misma ley protege el programa durante 50 años, contados desde el 1 de enero del año siguiente a su publicación o creación. Escríbelo sin margen de duda:

• el código fuente, los archivos de diseño y la documentación son del contratante;
• el repositorio está en una cuenta de tu empresa desde el primer día, con acceso del proveedor, y no al revés;
• dominio, hosting, base de datos, cuentas de correo transaccional y cuentas en las tiendas de apps se registran a nombre de tu empresa;
• las bibliotecas de terceros y los componentes que el proveedor reutiliza de otros proyectos quedan listados, con la licencia de cada uno.

7. Protección de datos (LGPD)

Si el sistema trata datos de clientes, pacientes o empleados, tu empresa es la responsable y el proveedor es el encargado del tratamiento. La LGPD exige que el encargado trate los datos según las instrucciones del responsable, y el encargado que incumple la ley responde solidariamente por los daños.

El riesgo es alto. Según el artículo 52, la multa simple puede llegar al 2% de la facturación de la empresa en Brasil en el último ejercicio, con un límite de R$ 50 millones por infracción, como detalla el comentario de Aurum a los artículos 52 a 54. El contrato debe decir dónde se guardan los datos, quién accede, qué medidas de seguridad son obligatorias, en cuánto tiempo se te comunica un incidente y qué pasa con los datos cuando termina el contrato.

8. Garantía y soporte tras la entrega

Los defectos aparecen después de que el sistema sale en línea. El contrato debe incluir un período de garantía en el que los errores se corrigen sin costo, y separar con claridad qué es defecto (algo que no funciona como se acordó) y qué es mejora (algo nuevo). Si hay mantenimiento después, necesita su propio contrato, con un tiempo de respuesta definido.

9. Salida: cómo cerrar llevándote todo

Nadie firma un contrato pensando en el final, y por eso esta cláusula suele faltar. Escribe cómo cualquiera de las partes puede rescindir, qué se paga hasta ese momento y, sobre todo, la obligación de entregar el código actualizado, los accesos, la documentación y las contraseñas en pocos días. Un contrato con una buena salida te permite cambiar de proveedor sin detener la empresa.

Señales de alerta antes de firmar

Algunas frases merecen una segunda lectura, y una pregunta directa al proveedor:

• “El código se entregará al final del proyecto.” ¿Por qué no desde el inicio, en un repositorio tuyo?
• “Plazo estimado de X semanas.” ¿Qué pasa si se excede?
• “Licencia de uso del software.” ¿Estás comprando un sistema o alquilándolo?
• “Los cambios se presupuestarán aparte.” ¿Cuál es la regla? ¿Quién aprueba?
• Ninguna mención a datos personales en un sistema que claramente guardará datos de clientes.

Si el proveedor se resiste a cambiar estos puntos, eso dice más sobre la relación que cualquier portafolio. Otras preguntas que vale la pena hacer están en preguntas antes de contratar un estudio de software.

Qué cambia esto para ti

Antes de pedir presupuesto, decide tres cosas: qué debe estar en línea en la primera versión, qué fecha importa para tu negocio y cuánto puedes invertir. Con eso, el proveedor puede hacer un diagnóstico y cerrar alcance, precio y plazo por escrito. Sin eso, cualquier contrato es una apuesta.

Después, lee el contrato con esta lista. Pide cambiar lo que sea vago. Y, si el proyecto involucra datos sensibles o un importe alto, lleva el texto a un abogado antes de firmar.

Cómo lo hacemos en el Studio

En Studio Responsivo, el precio se cierra después del diagnóstico y el plazo queda por escrito en el contrato. El código, los archivos y los accesos quedan a nombre del cliente. El equipo de desarrollo es del propio Studio, así que quien firma es quien entrega.

Así fue con LCX, empresa de turismo con operación en más de 10 países de Sudamérica: un sistema por país se convirtió en uno solo, en línea en 29 días. Todo sistema que entregamos sale con un agente de IA que se ejecuta a diario, señala fallos, sugiere mejoras y verifica que los datos tengan sentido.

Si estás por contratar un sistema y quieres un contrato que diga, por escrito, qué incluye, cuándo se entrega y de quién es, conoce cómo lanzamos sistemas y SaaS a medida.