Estudio Jurídico · Córdoba CapitalSitio institucional ↗ · Equipo ↗ · Contacto ↗
El Estudio ↗Equipo ↗Contacto ↗
Consultar al estudio ↗

Guía práctica · Derecho & Tecnología

Contrato de desarrollo de software: checklist antes de firmar

Alcance, hitos, aceptación, propiedad intelectual, repositorios, cambios, seguridad y salida.

Actualizada 7/08/2026Fuentes oficiales

Respuesta rápida

La cláusula más importante suele ser el alcance: qué se entrega y cómo se sabrá que está aceptado. Después hay que ordenar cambios, pagos, código, componentes preexistentes, soporte y continuidad. Si eso queda ambiguo, el conflicto aparece aunque ambas partes hayan actuado de buena fe.

Paso a paso

  1. Definí entregables

    Funcionalidades, plataformas, integraciones y documentación.

  2. Fijá hitos y aceptación

    Quién prueba, cuánto tiempo tiene y qué ocurre si hay defectos.

  3. Regulá cambios

    Proceso de change request, impacto en precio/plazo.

  4. Ordená propiedad intelectual

    Código nuevo, preexistente, librerías y licencias.

  5. Asegurá continuidad

    Repositorio, credenciales, documentación, backups y entrega al terminar.

  6. Separá mantenimiento

    Qué errores cubre garantía y qué evolutivos son un servicio nuevo.

Checklist

  • Propuesta
  • Especificación funcional
  • Cronograma
  • Repositorio
  • Licencias
  • SLA/soporte
  • Modelo de aceptación

Errores frecuentes que conviene evitar

  • Usar “app completa” sin especificación
  • Pagar 100% sin hitos si el proyecto es largo
  • No prever acceso a repositorio
  • Prometer titularidad de librerías ajenas
  • Confundir garantía de defectos con mantenimiento indefinido

Marco práctico en Argentina y Córdoba

La práctica contractual tecnológica no tiene un único tipo legal cerrado. La UBA separa expresamente software a medida, outsourcing, hosting, mantenimiento y cloud dentro de los contratos informáticos, lo que confirma la necesidad de adaptar cláusulas al servicio.

Preguntas frecuentes

¿Debo exigir código fuente?

Depende del modelo y continuidad; para software a medida suele ser central definir acceso/titularidad/licencia.

¿Qué pasa con open source?

Debe declararse y cumplir licencias.

¿Cómo se prueba que una funcionalidad fue aceptada?

Mediante criterios y procedimiento de aceptación documentado.

¿NDA separado o dentro del contrato?

Ambas opciones son posibles; lo importante es cobertura y coherencia.

Fuentes oficiales

Guía informativa general. No reemplaza la evaluación de evidencia, contratos, seguridad, plazos y jurisdicción.

WhatsApp