Qué conviene saber
Los conflictos de desarrollo suelen empezar por una especificación ambigua: “hacer una app” no define funcionalidades, integraciones, performance, hitos ni criterios de aceptación. El contrato debe separar alcance inicial, cambios y mantenimiento posterior.
La estrategia jurídica debe separar el hecho técnico de su calificación legal. Conservar información original, identificar quién controla los registros y evitar modificaciones innecesarias suele ser más útil que acumular capturas aisladas sin contexto.
En Córdoba y en la práctica
También debe definirse quién será titular del código y demás activos, qué componentes de terceros pueden utilizarse, acceso a repositorios, documentación, despliegue, seguridad y continuidad si termina la relación.
Información y documentación útil
- Propuesta y alcance funcional
- Backlog/roadmap
- Cronograma e hitos
- Repositorios
- Licencias de terceros
- Criterios de aceptación y soporte
Preguntas frecuentes
¿Pagar el desarrollo me hace dueño del código?
No debe asumirse; la titularidad/licencia debe quedar expresamente ordenada según contrato y ley.
¿Qué es change request?
Un mecanismo para acordar cambios de alcance, precio y plazo.
¿Conviene acceso al repositorio?
Para muchos clientes es importante para continuidad y control, según modelo.
¿Qué pasa con librerías open source?
Deben identificarse sus licencias y obligaciones antes de prometer titularidad exclusiva sobre todo el producto.
Fuentes oficiales y marco de referencia
- [S10] Ley 11.723 — Propiedad Intelectual, texto actualizado ↗
- [S15] UBA Derecho — Especialización en Derecho Informático ↗
Contenido informativo general. El encuadre depende de hechos, evidencia, contratos, jurisdicción y estado del asunto. Última revisión: 7 de agosto de 2026.