Contrato de Desarrollo de App: Propiedad del Código y Garantías

Si el contrato no lo dice, usted no es dueño del código. En Colombia el autor conserva la titularidad originaria y la ley solo presume una cesión limitada a la actividad habitual de quien encarga la obra. Exija una cláusula escrita de cesión total de derechos patrimoniales, entrega del repositorio completo y cuentas de tienda a su nombre.

Elegir proveedor y firmar con él son dos decisiones distintas. La primera se resuelve con criterios para elegir la empresa de desarrollo; la segunda se resuelve en el documento que ambos firman, y ahí es donde la mayoría de los compradores pierde. Hay contratos de decenas de millones de pesos que caben en dos páginas, sin anexo de alcance, sin una línea sobre propiedad intelectual y sin decir a nombre de quién quedan las cuentas de las tiendas. Esta guía es la lista de lo que debe estar escrito antes de que usted ponga la firma, con los rangos de referencia del mercado colombiano para negociar cada punto. No sustituye la asesoría de un abogado: le sirve para llegar a esa reunión sabiendo qué pedir.

¿Quién es dueño del código fuente si usted paga el desarrollo?

El pago, por sí solo, no lo convierte en titular del código. En Colombia el software está protegido por derecho de autor y el titular originario es siempre la persona que lo escribe. Cuando ese programador trabaja bajo contrato laboral o por encargo, la ley presume una transferencia de derechos patrimoniales hacia quien lo contrató, pero es una presunción limitada, no la propiedad plena del producto.

La presunción legal existe, pero se queda corta

La normativa colombiana (Ley 23 de 1982, con las modificaciones de la Ley 1450 de 2011) presume que, en obras creadas por encargo o bajo contrato de prestación de servicios, los derechos patrimoniales se transfieren a quien encarga en la medida necesaria para el ejercicio de sus actividades habituales. Esa frase es el problema. “En la medida necesaria” no dice si usted puede modificar el código, licenciarlo, venderlo con la empresa en una operación de compraventa o entregárselo a otro proveedor. Cada una de esas discusiones se resuelve en un juzgado si el contrato calla, y usted no quiere descubrirlo el día que necesite cambiar de equipo.

Derechos morales y derechos patrimoniales no son lo mismo

Los derechos morales —paternidad e integridad de la obra— son inalienables e irrenunciables: el programador siempre podrá decir que escribió ese código, y eso no le quita a usted ningún control comercial. Los que se negocian son los patrimoniales: reproducción, distribución, comunicación pública y, el más importante en software, transformación. Sin el derecho de transformación cedido, usted no puede contratar a otro equipo para evolucionar la app sin permiso del autor original. Es la cláusula que convierte una app en un activo o en un alquiler.

La cesión debe constar por escrito

La transferencia de derechos patrimoniales debe constar por escrito como condición de validez. La Ley 1915 de 2018 eliminó la exigencia de escritura pública o de reconocimiento ante notario, pero no la del documento, y dejó dos reglas supletorias que conviene conocer antes de firmar: si el contrato no menciona el tiempo, la transferencia queda limitada a cinco años; si no menciona el ámbito territorial, queda limitada al país donde se realiza. Un contrato que “cede los derechos” sin decir por cuánto tiempo ni dónde le está entregando mucho menos de lo que usted cree.

Pida que la cláusula diga, con todas las letras, que la cesión es total, exclusiva, para todas las modalidades de explotación conocidas, por el máximo término legal y sin límite territorial. Y no confunda dos registros distintos ante la Dirección Nacional de Derecho de Autor: el del soporte lógico, que es declarativo y sirve como prueba de existencia y fecha cierta, y el del acto de transferencia, que es el que hace la cesión oponible frente a terceros. El primero es opcional; el segundo conviene tramitarlo siempre.

Licencia de uso frente a cesión de derechos

Un proveedor puede ofrecer licencia en lugar de cesión y ser honesto al hacerlo, siempre que lo diga y lo refleje en el precio. El problema no es la licencia: es la licencia disfrazada de compra.

Las 10 cláusulas que debe tener un contrato de desarrollo de aplicaciones móviles

1. Objeto y alcance con anexo funcional. El alcance vive en un anexo con pantallas, flujos, integraciones y criterios de aceptación, no en un párrafo del contrato.
2. Cesión de derechos patrimoniales sobre el código, con efecto al pago del hito correspondiente y redacción completa.
3. Entrega del repositorio, la documentación y las credenciales, con plazo en días hábiles y acta firmada.
4. Titularidad de las cuentas de App Store, Google Play, backend, dominio y servicios de terceros a nombre de su empresa.
5. Hitos de pago atados a entregables verificables, no al calendario.
6. Garantía posventa y SLA de soporte con tiempos de respuesta y solución por severidad.
7. Control de cambios: cómo se pide, se estima y se aprueba una modificación de alcance.
8. Confidencialidad y tratamiento de datos personales, con el proveedor como encargado y usted como responsable.
9. Terminación anticipada y plan de salida: qué se entrega, en cuánto tiempo y qué se paga.
10. Inventario de componentes de terceros y sus licencias, con declaración de que ninguno compromete la explotación comercial.

Las cláusulas 2, 3 y 4 son el núcleo. Si un proveedor las acepta sin discutir, buena señal. Si las condiciona, se detiene la firma.

Cómo debe quedar redactada la cesión

La cláusula debe cubrir cuatro elementos: qué se cede (el código fuente, los objetos, la documentación técnica y los archivos de diseño), con qué alcance (todas las modalidades de explotación, sin límite de tiempo ni territorio), cuándo surte efecto (al pago del hito acordado, no antes) y qué se excluye. Ese último punto es legítimo: casi todas las empresas reutilizan librerías internas propias entre proyectos y no van a cederlas. La solución razonable es que el proveedor conserve la titularidad de esos componentes preexistentes y le otorgue a usted una licencia perpetua, irrevocable, gratuita y transferible para usarlos y modificarlos dentro de su aplicación. Sin esa licencia, un componente interno del proveedor puede dejar su app inservible el día que se rompa la relación.

Componentes de terceros y licencias abiertas

Toda app moderna se apoya en decenas de librerías externas. La mayoría usa licencias permisivas y no genera problemas; algunas licencias con efecto copiativo pueden obligar a publicar el código de lo que las incorpora, lo cual es incompatible con un producto comercial cerrado. Exija en el contrato un inventario de dependencias con su licencia y una declaración del proveedor de que ninguna restringe la explotación comercial ni la distribución en tiendas. Es media hoja en un anexo y elimina un riesgo que casi nadie revisa.

Qué se entrega y a nombre de quién

Esta es la tabla que conviene anexar al contrato tal cual, con una columna de “verificado” y una fecha. Los valores son rangos de referencia del mercado colombiano y varían con la tasa de cambio.

El punto crítico está en las dos filas de tienda. Publicar bajo la cuenta de la agencia “porque es más rápido” significa que las descargas, las reseñas acumuladas y la ficha quedan en un activo ajeno; si quiere el detalle de los requisitos y de quién son las cuentas de App Store y Google Play, ahí está explicado paso a paso. Y sobre el repositorio: la protección más barata del mundo es que el código viva desde el primer día en una organización de Git creada por usted, con el proveedor invitado como colaborador. Así no hay “entrega” que negociar al final, porque el código nunca estuvo del otro lado.

Hitos de pago: cómo repartir el dinero sin perder poder de negociación

Dos reglas simples: nunca el 100 % por adelantado y nunca el pago final antes de que la app esté publicada y funcionando. Cada hito se paga contra un entregable que usted pueda instalar, abrir y probar. Este ejemplo usa un proyecto de referencia de $60.000.000 COP; los porcentajes son lo que importa, el valor total dependerá de su alcance y de cómo pedir una cotización comparable.

La retención final del 10 % es la cláusula más útil de todo el contrato y la que más resistencia genera. Es también la única forma de que la atención al último lote de errores no dependa de la buena voluntad de nadie. Si el proveedor la rechaza de plano, pregunte por qué; si la acepta con un plazo de 60 días, ya está negociando bien.

Garantía: qué es razonable exigir tras la entrega

La garantía cubre defectos atribuibles al desarrollo: lo que se construyó no hace lo que el anexo de alcance dice que debía hacer. No cubre funcionalidades nuevas, cambios de alcance ni fallas de servicios de terceros ajenos al proveedor. La discusión honesta está en el punto intermedio —actualizaciones de sistema operativo y cambios en las APIs de las tiendas—, y conviene definirlo por escrito: lo normal es que las adaptaciones obligatorias del primer año entren en el plan de mantenimiento, no en la garantía.

Un detalle que casi nadie pide: que la tarifa de soporte por hora quede congelada durante los primeros doce meses. Sin eso, el proveedor que tiene su código y sus cuentas puede fijar el precio que quiera cuando usted más lo necesita.

Confidencialidad, datos personales y cumplimiento

Si su app recoge datos de usuarios —y casi todas lo hacen—, usted es el responsable del tratamiento ante la Ley 1581 de 2012 y el proveedor actúa como encargado. Eso debe quedar por escrito, con obligaciones concretas: usar los datos solo para ejecutar el contrato, no transferirlos a terceros sin autorización, aplicar medidas de seguridad razonables, notificarle cualquier incidente en un plazo definido y devolver o eliminar los datos al terminar la relación.

Agregue confidencialidad bidireccional con vigencia posterior a la terminación, prohibición de usar sus datos de producción en ambientes de prueba y una regla sobre el portafolio: si el proveedor quiere mostrar el proyecto como caso, que lo pida por escrito. También conviene una cláusula de no divulgación de credenciales y una lista de personas autorizadas a acceder a los ambientes productivos, actualizable por correo.

Terminación anticipada y qué pasa si la empresa desarrolladora cierra

El plan de salida es la parte del contrato que se redacta cuando todo va bien y se lee cuando todo va mal. Debe decir tres cosas: que usted paga lo ejecutado y aprobado hasta el hito en curso, que el proveedor entrega en un plazo corto —de 5 a 10 días hábiles— el repositorio, la documentación, las credenciales y los archivos de diseño, y que ninguna de esas entregas puede condicionarse a pagos futuros ni a la firma de un contrato de mantenimiento.

Si la empresa desarrolladora cierra, su exposición depende de decisiones que ya tomó al firmar. Con el repositorio en su propia organización, las cuentas de tienda a su nombre, las llaves de firma en su poder y la documentación entregada, el impacto es un cambio de equipo: incómodo, pero manejable. Sin eso, el cierre del proveedor equivale a perder el producto. En proyectos grandes se puede añadir un depósito de fuentes con un tercero, que libera el código ante causales pactadas; en proyectos medianos, entregar el repositorio en cada hito cumple la misma función y no cuesta nada.

Cláusulas trampa que debe negociar antes de firmar

• Cesión condicionada a mantener vigente el contrato de mantenimiento.
• “Licencia de uso perpetua” presentada como si fuera propiedad.
• Cesión sin plazo ni territorio escritos, que por regla supletoria queda limitada a cinco años y al país donde se firma.
• Titularidad compartida del código: en la práctica, ninguno de los dos decide solo.
• Publicación bajo la cuenta de desarrollador de la agencia, con promesa de traspaso posterior.
• Garantía “sujeta a disponibilidad del equipo”, sin tiempos de respuesta.
• Alcance descrito solo en la propuesta comercial, sin anexo funcional firmado.
• Penalidades por retraso solo para el cliente, ninguna para el proveedor.
• Silencio sobre las credenciales: el contrato habla del código, pero no de las llaves de firma ni de los accesos.
• Renovación automática del soporte con incremento no definido.
• Jurisdicción y ley aplicable fuera de Colombia en un contrato firmado entre dos empresas colombianas.

Checklist final antes de poner la firma

• El anexo de alcance está firmado por ambas partes y tiene criterios de aceptación.
• La cesión de derechos patrimoniales es total, escrita, con plazo y territorio expresos, y sin condiciones posteriores al pago.
• Los componentes preexistentes del proveedor vienen con licencia perpetua, irrevocable y transferible.
• El repositorio está en una organización creada por usted, con acceso desde la semana uno.
• Las cuentas de App Store y Google Play están a nombre de su empresa, con usted como propietario.
• Las llaves de firma y los certificados están guardados en su gestor de contraseñas.
• Los hitos de pago están atados a entregables instalables y hay una retención final del 10 %.
• La garantía tiene duración, severidades y tiempos de respuesta escritos.
• El mantenimiento posterior tiene precio pactado y tarifa por hora congelada por 12 meses.
• Hay cláusula de tratamiento de datos con usted como responsable y el proveedor como encargado.
• El plan de salida define plazos de entrega y prohíbe condicionar esa entrega a pagos futuros.
• El inventario de licencias de terceros está anexado y declarado libre de restricciones comerciales.

Firmar bien es la mitad del proyecto

Un contrato de desarrollo de aplicaciones móviles no protege contra un mal equipo: protege contra la dependencia. Si el código, las cuentas y las llaves son suyas desde el primer día, el peor escenario posible es cambiar de proveedor. Si no lo son, cualquier desacuerdo se convierte en una negociación en la que usted no tiene cartas. Los doce puntos del checklist no encarecen el proyecto: solo hacen explícito lo que un proveedor serio ya pensaba entregar.

Si está por firmar y quiere una segunda lectura del contrato antes de hacerlo, puede escribirme. Soy Alejandro Verjel, consultor Google Partner certificado; trabajo en marketing digital desde 2009 —más de 16 años— y tengo una calificación de 4.9 estrellas con 30 reseñas en Google. Desarrollo y mantengo mis propias aplicaciones publicadas, Chately, Rankiamos y VialKy, así que firmo, publico y mantengo bajo las mismas reglas que recomiendo aquí. Si además está evaluando crear una app para su negocio, reviso el alcance con usted antes de que llegue a la mesa de firma. Atiendo empresas en Bogotá, Medellín, Cali, Barranquilla, Bucaramanga, Cúcuta y toda Colombia de forma remota. Escríbame al WhatsApp +57 300 208 1105.