Contrato de desarrollo de software: las 10 cláusulas que debes exigir

En este artículo

1. ¿Qué tipo de contrato se usa para desarrollar software en Perú?
2. Las 10 cláusulas de un contrato de desarrollo de software
3. 1. Objeto y alcance
4. 2. Entregables y plazos
5. 3. Precio y pagos por hitos
6. 4. Gestión de cambios
7. 5. Pruebas y aceptación
8. 6. Propiedad intelectual y código fuente
9. 7. Confidencialidad y datos personales
10. 8. Garantía
11. 9. Mantenimiento y soporte
12. 10. Terminación y salida
13. Lista de verificación antes de firmar
14. En resumen
15. Preguntas frecuentes

Muchos sistemas se encargan con una cotización aprobada por WhatsApp y un apretón de manos. Funciona mientras todo va bien. El problema aparece cuando hay un retraso, un desacuerdo sobre lo que estaba incluido o cuando el proveedor deja de responder y nadie sabe de quién es el código.

Esta guía repasa las diez cláusulas que debes exigir en un contrato de desarrollo de software en el Perú, con lo que debe decir cada una y por qué. Es una lista para revisar propuestas y conversar con tu proveedor y tu abogado, no un modelo de contrato: cada proyecto necesita su redacción. En CONIT trabajamos con estas condiciones en los sistemas que desarrollamos, y las compartimos para que cualquier empresa sepa qué pedir.

¿Qué tipo de contrato se usa para desarrollar software en Perú?

Lo habitual es un contrato de locación de servicios o un contrato de obra, figuras del Código Civil (artículos 1764 y 1771), complementado con las reglas de la Ley sobre el Derecho de Autor para la propiedad del programa. La locación encaja mejor cuando se pagan horas o un servicio continuo; el contrato de obra, cuando se paga por un resultado concreto.

Elegir la figura es trabajo de tu abogado. Lo que te toca a ti es asegurarte de que, sea cual sea, el contrato responda las diez preguntas de esta lista.

Las 10 cláusulas de un contrato de desarrollo de software

Esta tabla resume las cláusulas y la pregunta que responde cada una. Debajo las explicamos una por una.

1. Objeto y alcance

El alcance dice qué se va a construir, y debe ser tan detallado que no admita dos lecturas. La mejor forma es anexar el documento de requerimientos al contrato y decir que forma parte de él.

Debe incluir los módulos, las funciones, los perfiles de usuario, las integraciones (pasarela de pagos, facturación electrónica, WhatsApp) y, muy importante, lo que no está incluido. Si todavía no tienes requerimientos escritos, usa nuestra plantilla de requerimientos.

2. Entregables y plazos

Esta cláusula dice qué recibes en cada etapa y en qué fecha. Un plazo total sin hitos intermedios no te deja saber si el proyecto va bien hasta que ya es tarde.

Pide un cronograma con entregables concretos (prototipo aprobado, módulo 1 en entorno de prueba, acta de aceptación, paso a producción) y una regla para los retrasos: qué pasa si se retrasa el proveedor y qué pasa si el retraso es por demoras tuyas en revisar o en entregar accesos.

3. Precio y pagos por hitos

El precio debe estar dividido en pagos ligados a entregables aprobados, no a fechas del calendario. Así pagas por avance comprobado.

Un esquema común es un adelanto al firmar, un pago al aprobar el diseño, pagos por cada módulo y el saldo con la aceptación final. La cláusula debe decir si el precio incluye IGV, qué gastos de terceros paga cada parte (servidor, dominio, licencias, comisiones de la pasarela) y en qué moneda se paga. Las etapas y su lógica están en cómo se desarrolla un sistema a medida.

4. Gestión de cambios

Esta cláusula dice qué pasa cuando pides algo que no estaba en el alcance, y evita la mayor fuente de peleas en un proyecto de software.

Lo sano es un procedimiento simple: pides el cambio por escrito, el proveedor responde con su impacto en plazo y costo, tú lo apruebas o no, y solo entonces se hace. Sin esta cláusula, cada cambio se discute al final, cuando ya nadie recuerda qué se acordó.

5. Pruebas y aceptación

La cláusula de aceptación dice cómo se da por terminado cada entregable: quién prueba, con qué casos, en cuántos días y qué pasa si encuentras errores.

Pide un plazo razonable para revisar (por ejemplo, cinco o diez días hábiles), que los errores importantes se corrijan antes de aceptar y que la aceptación se firme por escrito. Cuidado con las cláusulas que dan por aceptado un entregable si no respondes en pocos días: está bien que exista un plazo, pero que sea realista para tu equipo.

6. Propiedad intelectual y código fuente

Esta es la cláusula más importante para un cliente en el Perú, porque la ley no te favorece si el contrato calla. El Decreto Legislativo 822 presume que los derechos patrimoniales sobre un programa son del productor, que suele ser la empresa desarrolladora (artículos 70 y 71), y exige que las cesiones y licencias consten por escrito, una por cada forma de uso (artículos 89 y 95). Texto revisado el 10 de octubre de 2026.

La cláusula debe decir:

• Que se te ceden los derechos patrimoniales sobre el código desarrollado para el proyecto.
• Que recibirás el código fuente completo, la documentación y las instrucciones de instalación, en cada etapa o al final.
• Que la base de datos y la información son tuyas.
• Qué componentes de terceros o de código abierto se usan y bajo qué licencias.

Lo explicamos a fondo en propiedad del código fuente en un desarrollo a medida.

Lo que hacemos en CONIT

Construimos sistemas a medida y páginas web para empresas de todo el Perú con propuesta por módulos, pagos por hito, garantía y entrega del código fuente al cliente, todo por escrito. Así trabajamos proyectos como el catálogo inmobiliario de Inmobiliaria Solís o los sistemas de Adventur. Conoce el servicio de sistemas a medida.

7. Confidencialidad y datos personales

Tu proveedor conocerá tus procesos, tus precios y probablemente los datos de tus clientes. El contrato debe protegerlos con dos cláusulas distintas: confidencialidad y tratamiento de datos personales.

La de confidencialidad cubre tu información de negocio. La de datos personales responde a la Ley 29733: si el desarrollador accede a datos de tus clientes, actúa como encargado de tratamiento. El reglamento vigente le prohíbe transferirlos a terceros sin autorización y limita su conservación a un máximo de dos años desde el último encargo, salvo excepciones legales (DS 016-2024-JUS, artículo 31). Además, ante un incidente de seguridad grave, el responsable debe notificar a la Autoridad Nacional de Protección de Datos Personales en un máximo de 48 horas (artículo 34). Pacta que el proveedor te avise de inmediato si detecta un incidente, para que puedas cumplir ese plazo.

8. Garantía

La garantía obliga al proveedor a corregir sin costo los errores del sistema entregado durante un tiempo después de la aceptación. No hay un plazo legal fijo para esto en software a medida: se pacta.

La cláusula debe decir cuánto dura, desde cuándo se cuenta (normalmente desde la aceptación), qué cubre (errores de lo que se construyó) y qué no cubre (cambios nuevos, problemas causados por terceros o por modificaciones hechas por otro proveedor), además del tiempo de respuesta.

9. Mantenimiento y soporte

El mantenimiento empieza donde termina la garantía, y debe quedar definido antes de firmar, no cuando el sistema ya está en uso. Puede ir en el mismo contrato o en uno aparte.

Debe decir qué incluye (correcciones, actualizaciones de seguridad, servidor, copias de seguridad, horas de mejoras), los tiempos de respuesta según la gravedad y el costo mensual. Una agencia peruana estima el mantenimiento entre 15 % y 25 % del costo inicial por año (Adratech, revisado el 10 de octubre de 2026). Más detalle en mantenimiento de software.

10. Terminación y salida

La cláusula de salida dice cómo se termina el contrato y qué te llevas. Es la que nadie lee al firmar y la que más importa cuando algo sale mal.

Debe cubrir:

• Las causas por las que cualquiera de las partes puede terminar el contrato.
• Cómo se pagan los trabajos ya entregados y aceptados.
• La entrega del código, la base de datos, la documentación y los accesos en un plazo concreto.
• La devolución o eliminación de los datos personales que tenga el proveedor.
• Que el dominio, el servidor y las cuentas de servicios estén a nombre de tu empresa desde el inicio.

Lista de verificación antes de firmar

Usa esta lista para revisar cualquier propuesta o contrato. Si falta alguno de estos puntos, pídelo por escrito:

• Requerimientos anexos al contrato, con lo que no está incluido.
• Cronograma con entregables y una regla para los retrasos.
• Pagos ligados a entregables aprobados, con IGV y gastos de terceros claros.
• Procedimiento escrito para pedir cambios.
• Plazo de revisión y aceptación por escrito.
• Cesión de derechos patrimoniales y entrega del código fuente.
• Confidencialidad y cláusula de datos personales.
• Garantía con plazo y alcance.
• Mantenimiento con alcance, tiempos de respuesta y costo mensual.
• Salida con entrega de código, datos y accesos.

Y un último consejo: revisa el contrato con un abogado antes de firmar. Cuesta poco comparado con lo que protege.

En resumen

• Un contrato de desarrollo de software debe tener al menos diez cláusulas: alcance, entregables, pagos por hitos, cambios, aceptación, propiedad del código, datos personales, garantía, mantenimiento y salida.
• Anexa los requerimientos al contrato: lo que no está escrito, no está incluido.
• En el Perú, si el contrato no dice nada, la ley presume que los derechos sobre el programa son del productor: pacta por escrito la cesión y la entrega del código fuente.
• Si el proveedor accede a datos personales, es encargado de tratamiento según la Ley 29733 y debe protegerlos, no transferirlos y devolverlos al terminar.
• Define la garantía y el mantenimiento antes de firmar, con plazos y costos.
• La cláusula de salida debe asegurar que te lleves el código, la base de datos, la documentación y los accesos.

Preguntas frecuentes

¿Qué debe incluir un contrato de desarrollo de software?

Como mínimo: objeto y alcance con los requerimientos anexos, entregables y plazos, forma de pago por hitos, gestión de cambios, pruebas y aceptación, propiedad intelectual y entrega del código fuente, confidencialidad y datos personales, garantía, mantenimiento y soporte, y condiciones de terminación y salida.

¿Qué tipo de contrato es el desarrollo de software en Perú?

Suele redactarse como un contrato de locación de servicios o como un contrato de obra del Código Civil, a los que se suman las reglas de la Ley sobre el Derecho de Autor para la propiedad del programa. Cuál conviene depende de si se paga por un resultado concreto o por horas de trabajo; consúltalo con un abogado.

¿Es obligatorio que el contrato diga quién es dueño del código?

No es obligatorio, pero es indispensable. Si el contrato no lo dice, el Decreto Legislativo 822 presume que los derechos patrimoniales son del productor del programa, que suele ser la empresa desarrolladora. Para que sean tuyos, la cesión debe constar por escrito.

¿Cuánto debe durar la garantía de un software?

No hay un plazo legal fijo para esto; se pacta. Lo habitual en el mercado es un periodo de garantía de algunos meses desde la aceptación, durante el cual el proveedor corrige sin costo los errores del sistema entregado. Lo importante es que el plazo y lo que cubre queden por escrito.

¿El desarrollador puede ver los datos de mis clientes?

Solo en la medida necesaria para el servicio y bajo las condiciones del contrato. Si accede a datos personales, actúa como encargado de tratamiento según la Ley 29733: no puede transferirlos a terceros sin autorización y debe devolverlos o eliminarlos al terminar. Por eso el contrato debe incluir una cláusula de datos personales.

¿Qué pasa si quiero cambiar de proveedor a mitad del proyecto?

Depende de la cláusula de terminación. Un buen contrato dice cómo se pagan los trabajos ya entregados, cómo se entrega el código y la documentación hasta ese momento y en qué plazo, para que otro proveedor pueda continuar.