Qué debería contener un contrato de desarrollo de software

Contratar el desarrollo de un producto de software es una decisión estratégica para cualquier empresa. Se está invirtiendo tiempo, dinero y expectativas en algo que —si sale bien— puede transformar un negocio. Pero la contracara es que, si algo sale mal, los costos de corregir el rumbo pueden ser altos y difíciles de absorber.

El contrato de desarrollo de software es la principal herramienta que tienen ambas partes para alinear expectativas, definir responsabilidades y establecer qué pasa cuando las cosas no salen como se planearon. Sin embargo, muchas empresas —sobre todo las que no tienen experiencia previa contratando tecnología— firman acuerdos que dejan demasiados cabos sueltos, ya sea por confianza en el proveedor, por urgencia de arrancar o por no saber qué temas deberían estar cubiertos.

Este artículo lista los temas y áreas que conviene tener presentes al revisar o negociar un contrato de desarrollo. No es asesoría legal: para redactar cláusulas específicas, consultá con un abogado especializado. Pero sí es una guía de lo que no debería faltar para proteger tu inversión.

Alcance del proyecto: qué se va a construir y cómo se define "terminado"

El corazón de cualquier contrato de desarrollo es la definición del alcance. Si el alcance es ambiguo, todo lo demás —plazos, presupuesto, criterios de aceptación— se vuelve inaplicable, porque ninguna de las partes va a tener la misma idea de qué era lo que había que entregar.

Un contrato sólido debería incluir, como mínimo:

• Descripción funcional del producto: qué debe hacer el sistema, para quién, bajo qué condiciones. No es necesario un documento de cien páginas, pero sí una descripción suficiente como para que alguien externo al proyecto pueda entender qué se está contratando.
• Lista de funcionalidades incluidas y excluidas: tan importante como decir qué se incluye es decir qué no se incluye. Si el proyecto contempla una aplicación web pero no una aplicación móvil, debería estar escrito. Si incluye integración con un sistema de pagos pero no con el ERP de la empresa, también. Las ambigüedades en este punto son la principal fuente de conflictos durante el desarrollo.
• Criterios de aceptación: cómo se determina que una funcionalidad está terminada. Puede ser una lista de condiciones, pruebas que deben pasar, o un proceso de revisión y aprobación. Sin criterios de aceptación definidos, el proveedor puede considerar algo como terminado mientras el cliente lo ve a medio hacer.

Plazos y cronograma de entregas

El tiempo es uno de los recursos más sensibles en un proyecto de software. Un retraso de semanas o meses puede significar perder una oportunidad de mercado, incumplir con un inversor o postergar ingresos proyectados.

El contrato debería contemplar:

• Cronograma de hitos o entregables parciales: en lugar de una única fecha de entrega final, dividir el proyecto en etapas con fechas definidas permite detectar desvíos temprano. Si el primer hito se entrega con tres semanas de retraso, es una señal para revisar el resto del plan antes de que el proyecto entero se descarrile.
• Consecuencias por incumplimiento de plazos: qué pasa si el proveedor no entrega en la fecha acordada. Algunas opciones: multas por día de retraso, derecho del cliente a rescindir el contrato después de un cierto período sin entrega, o ajustes en el precio.
• Dependencias del cliente: muchos retrasos vienen del lado del cliente: no entregar contenidos, no dar feedback a tiempo, no proveer accesos a sistemas que se necesitan integrar. El contrato debería dejar claro que los plazos del proveedor dependen de que el cliente cumpla con sus propias obligaciones en tiempo y forma.

Propiedad intelectual y código fuente

Este es uno de los puntos que más controversia genera y que muchas empresas pasan por alto hasta que es demasiado tarde. La pregunta central es: cuando el proyecto termine, ¿quién es dueño del código?

Lo esperable en un contrato de desarrollo a medida es que el cliente sea el dueño del código fuente y de la propiedad intelectual del producto desarrollado. El proveedor está siendo contratado para construir algo por encargo, y el resultado de ese trabajo debería pertenecer a quien lo pagó.

Temas que deberían estar cubiertos:

• Transferencia de propiedad intelectual: una cláusula explícita que establezca que todo el código, diseños, documentación y materiales producidos durante el proyecto pasan a ser propiedad del cliente al momento del pago completo.
• Entrega del código fuente: no solo el producto funcionando, sino el código fuente completo, incluyendo instrucciones para compilarlo o desplegarlo. Sin el código fuente, el cliente queda atado de por vida al proveedor original para cualquier modificación futura.
• Componentes de terceros: los proyectos de software suelen usar bibliotecas, frameworks y herramientas de terceros que tienen sus propias licencias. El contrato debería aclarar que el proveedor es responsable de usar componentes que no restrinjan el uso comercial del producto final. No querés descubrir seis meses después del lanzamiento que parte de tu sistema usa una biblioteca con una licencia que te obliga a abrir tu código o pagar regalías.

Precio, forma de pago y costos adicionales

El aspecto económico del contrato va más allá del número total. La estructura de pagos determina los incentivos de ambas partes durante el proyecto.

Aspectos a considerar:

• Precio total y forma de pago: si es precio fijo o por horas, y en qué moneda. En proyectos de desarrollo, es común atar los pagos a la entrega de hitos concretos en lugar de pagar por tiempo transcurrido. Así, el proveedor tiene un incentivo alineado con el avance real del proyecto.
• Qué incluye y qué no incluye el precio: hospedaje, dominio, certificados de seguridad, licencias de software de terceros, mantenimiento posterior a la entrega. Si no está especificado que algo está incluido, el proveedor puede facturarlo como adicional.
• Gastos de cambio de alcance: en todo proyecto de software aparecen ajustes sobre la marcha. El contrato debería establecer un mecanismo para manejar esos cambios: cómo se solicitan, cómo se cotizan, y cómo afectan a los plazos. Sin ese mecanismo, cada cambio se convierte en una negociación desde cero.
• Garantía post-entrega: un período —típicamente de treinta a noventa días— durante el cual el proveedor corrige sin costo adicional los errores que se detecten en lo que entregó. Pasado ese período, las correcciones o nuevas funcionalidades se facturan aparte como mantenimiento.

Confidencialidad y protección de datos

Durante el desarrollo, el proveedor va a tener acceso a información sensible del negocio: procesos internos, datos de clientes, estrategia comercial, proyecciones financieras. Si el producto que se está construyendo va a manejar datos de clientes —propios o de terceros—, la responsabilidad es todavía mayor.

Lo que el contrato debería contemplar:

• Acuerdo de confidencialidad: establecer que toda la información compartida durante el proyecto es confidencial y no puede ser divulgada ni utilizada para otros fines.
• Propiedad de los datos: los datos que el sistema genera o procesa —información de clientes, transacciones, reportes— pertenecen al cliente, no al proveedor.
• Obligaciones de seguridad: el proveedor debe comprometerse a seguir prácticas de desarrollo seguras y a proteger los datos a los que tiene acceso. Si bien los detalles técnicos pueden ir en un anexo, el contrato principal debería dejar claro que la seguridad es una obligación contractual, no una cortesía.
• Devolución o destrucción de datos al finalizar: si el proveedor almacenó información del cliente en sus propios servidores durante el desarrollo, el contrato debería establecer que, al terminar el proyecto o al rescindir el contrato, esa información debe ser devuelta al cliente y eliminada de los sistemas del proveedor.

Soporte y mantenimiento

El desarrollo de software no termina cuando se entrega la primera versión. Los sistemas requieren mantenimiento: actualizaciones de seguridad, corrección de errores que aparecen con el uso, adaptaciones a cambios en los sistemas con los que se integra.

El contrato debería distinguir entre:

• Garantía post-entrega (ya mencionada): corrección gratuita de errores durante un período acotado.
• Mantenimiento evolutivo: nuevas funcionalidades o mejoras, que se presupuestan aparte.
• Soporte: atención de consultas, resolución de incidencias, monitoreo. Puede tener diferentes niveles de servicio —tiempo de respuesta, horario de atención, canal de comunicación— según lo que el negocio necesite y esté dispuesto a pagar.

Sin un acuerdo de mantenimiento, el cliente se encuentra con un sistema que funciona hasta que algo se rompe —y en software, algo siempre se rompe, ya sea por una actualización del navegador, un cambio en la API de un servicio externo o un error que solo aparece con cierto volumen de datos—. En ese momento, el proveedor original puede no tener disponibilidad, haber cambiado sus precios o simplemente no estar interesado en tomar un trabajo chico. La recomendación general es no dejar el proyecto sin una previsión de mantenimiento, aunque sea mínima.

Terminación del contrato y salida ordenada

Idealmente, el proyecto llega a buen puerto y ambas partes quedan satisfechas. Pero los contratos existen justamente para cubrir los escenarios en los que las cosas no salen como se esperaba.

El contrato debería contemplar:

• Causales de terminación: bajo qué condiciones cualquiera de las partes puede dar por terminado el contrato antes de la finalización del proyecto. Incumplimiento reiterado de plazos, falta de pago, cambio en las condiciones del negocio que haga inviable el proyecto.
• Procedimiento de salida: si el contrato se termina antes de tiempo, ¿qué pasa con lo construido hasta ese momento? Lo razonable es que el cliente reciba todo el código y la documentación generada hasta la fecha de terminación, y que el proveedor reciba el pago proporcional por el trabajo efectivamente realizado.
• Transición a otro proveedor: si el cliente decide continuar el proyecto con otro equipo, ¿qué cooperación debe prestar el proveedor saliente? Esto puede incluir transferencia de conocimiento, entrega de accesos y documentación, y un período de transición durante el cual el proveedor saliente resuelve dudas del entrante.

La peor posición en la que puede quedar un cliente es con un proyecto a medio hacer, sin acceso al código y con un proveedor que no responde. Un contrato bien diseñado debería hacer que esa situación sea imposible.

Resolución de conflictos

Cuando hay diferencias entre las partes —sobre el alcance, la calidad, los plazos—, tener un mecanismo de resolución definido de antemano ahorra tiempo, dinero y desgaste.

Opciones habituales:

• Negociación directa entre las partes: un período definido durante el cual las partes intentan resolver la diferencia sin escalar.
• Mediación: un tercero neutral ayuda a las partes a llegar a un acuerdo, sin imponer una decisión.
• Arbitraje: un árbitro —o un panel de árbitros— escucha a ambas partes y emite una decisión vinculante. Suele ser más rápido y menos costoso que un juicio.
• Jurisdicción aplicable: en qué país y bajo qué leyes se resuelven los conflictos. Si el proveedor está en otro país, este punto es particularmente relevante.

Anexos: lo que no entra en el cuerpo del contrato

Buena parte de la sustancia de un contrato de desarrollo de software suele estar en los anexos. Es una práctica habitual y recomendable: el cuerpo del contrato establece las condiciones generales, y los anexos detallan lo específico del proyecto.

Anexos que suelen acompañar un contrato de desarrollo:

• Especificación funcional detallada: el "qué" del proyecto con suficiente nivel de detalle.
• Diseño de interfaz o prototipos: si ya existen, ayudan a anclar expectativas visuales.
• Cronograma de hitos y entregables: fechas, responsables y criterios de aceptación para cada etapa.
• Acuerdo de nivel de servicio (SLA): para la etapa de soporte y mantenimiento posterior a la entrega.
• Lista de componentes de terceros: bibliotecas, APIs y servicios externos que se van a utilizar, con sus licencias.

Los anexos forman parte del contrato y tienen la misma fuerza legal que el cuerpo principal. No los trates como documentación accesoria.

El contrato de desarrollo de software no debería verse como un trámite burocrático que frena el arranque del proyecto, sino como la herramienta que permite arrancar con expectativas alineadas y reglas claras para cuando algo se desvía del plan. Dedicarle tiempo a la etapa contractual no es perder tiempo de desarrollo: es proteger la inversión que estás a punto de hacer.