Propiedad del código y contrato de desarrollo de una app

Cuando encargás una app, una de las preguntas más importantes es quién es dueño de qué cuando el proyecto termina. La propiedad del código y el contrato de desarrollo de una app definen si podés llevar tu aplicación a otro proveedor, modificarla o venderla. Esta guía repasa las cláusulas que conviene mirar antes de firmar.

Esta guía es informativa y no constituye asesoramiento legal. Los contratos y la propiedad intelectual dependen de cada caso y de la normativa vigente. Antes de firmar, consultá con un abogado, preferentemente con experiencia en software.

Por qué no es obvio que «lo pagado es tuyo»

Mucha gente supone que, al pagar el desarrollo, recibe todo. Pero en software conviven varias cosas distintas: el código fuente escrito a medida, las librerías de terceros con sus propias licencias, el diseño, las cuentas de servicios y los datos de los usuarios. Si el contrato no lo aclara, pueden surgir discusiones, y la ley de propiedad intelectual tiene reglas que no siempre coinciden con lo que las partes imaginaban. Por eso conviene dejarlo por escrito.

Las cláusulas que conviene mirar

1. Titularidad del código y de los entregables

Debe quedar claro si el código a medida, el diseño y la documentación se ceden al cliente, cuándo (al firmar, al pagar el total, al entregar) y con qué alcance. Una alternativa es que el proveedor conserve la titularidad y otorgue una licencia de uso; no es ilegítimo, pero cambia mucho lo que podés hacer, así que debe ser una decisión consciente.

2. Componentes de terceros y código abierto

Casi todas las apps usan librerías ajenas, cada una con una licencia. Preguntá si hay componentes con licencias que impongan obligaciones, y si el proveedor reutiliza código propio previo en tu proyecto. Eso suele ser normal; lo importante es que se informe y que tengas el derecho de uso que necesitás.

3. Entrega del código fuente

No alcanza con recibir la app instalable. Aclarar que se entrega el código fuente completo, en qué repositorio, con qué instrucciones para compilarlo y publicarlo, y en qué momentos. Si el código vive solo en la cuenta del proveedor, dependés de él.

4. Cuentas y accesos

Las cuentas de las tiendas, el dominio, el hosting, el servicio de notificaciones y las claves de firma deberían estar a tu nombre o ser transferibles. Es una de las fuentes de problemas más comunes cuando se cambia de proveedor.

5. Alcance, cambios y aceptación

El contrato debería describir qué se construye, cómo se pide un cambio, cómo se acepta cada entrega y qué ocurre con lo que quedó fuera del alcance. Un documento de requisitos claro, como el que se describe en cómo documentar los requisitos de una app, reduce las ambigüedades.

6. Pagos e hitos

Cómo se paga: por hitos, por horas o por mensualidad; qué pasa si se demora una entrega o una aprobación; y cómo se factura. Si hay dudas fiscales, consultá a tu contador sobre los comprobantes ante ARCA.

7. Garantía, soporte y mantenimiento

Qué errores se corrigen sin costo y por cuánto tiempo, y qué se considera una mejora aparte. Lo desarrollamos en mantenimiento de una app. Desconfiá de las promesas de «garantía total» sin condiciones escritas.

8. Datos personales y confidencialidad

Si la app trata datos de personas, el contrato debería prever quién es responsable de qué, cómo se resguardan y qué pasa con ellos al terminar la relación. En Argentina rige la Ley 25.326 de Protección de Datos Personales; más contexto en datos personales en apps. También conviene un acuerdo de confidencialidad sobre tu idea y tu negocio.

9. Terminación del contrato

Cómo se puede rescindir, qué se entrega si el proyecto se corta a la mitad y cómo se calcula lo ya trabajado. Pensar en el final al principio es incómodo, pero evita conflictos.

10. Mención del proveedor y portfolio

Algunos proveedores piden poder mostrar el proyecto en su portfolio. Es negociable: aclarar si se permite, con qué límites y si se puede mencionar tu marca.

Señales de alerta

• No hay contrato escrito, solo un mensaje o un presupuesto.
• El proveedor se niega a entregar el código o a transferir cuentas.
• El código queda «en custodia» sin plazos ni condiciones claras.
• Las cláusulas de cambios o de pagos son vagas.

Cómo prepararte antes de ver al abogado

1. Escribí qué querés poder hacer con la app en el futuro: venderla, cambiar de proveedor, sumar socios.
2. Pedí el borrador del contrato con tiempo y subrayá lo que no entiendas.
3. Llevá el alcance y el presupuesto, porque el contrato debe ser coherente con ellos.

Este tema es parte de elegir bien con quién trabajar; la guía para elegir un desarrollador ofrece un checklist complementario. Si estás evaluando un proyecto y querés conversar cómo lo planteamos desde Rosario, escribinos desde el formulario de contacto.