Contratas un sistema a medida, pagas y  en unos meses lo tienes funcionando. Hasta ahí todo bien. El problema aparece después: cuando quieres cambiar algo, cuando el proveedor sube sus tarifas o  cuando simplemente necesitas que otro equipo continúe el trabajo. Ahí es cuando muchas empresas descubren que no tienen el código o que lo tienen, pero no pueden hacer nada útil con él.

Y bueno, esto no siempre pasa por mala intención del proveedor. La mayoría de las veces pasa porque nunca quedó claro, desde el contrato, qué pasaría si la relación terminaba.

Los riesgos reales de no tener control sobre tu propio sistema

• Dependencia total del proveedor. Sin acceso real al código, cualquier cambio  por pequeño que sea pasa obligatoriamente por ellos, en sus tiempos y a su tarifa.
• Propiedad intelectual poco clara. Si el contrato no especifica quién es dueño del código, esa ambigüedad se vuelve un problema justo cuando más te importa: al querer cambiar de proveedor.
• Deuda técnica que no puedes ver. Un código mal documentado se convierte en algo que ningún otro equipo quiere tocar, porque nadie puede auditarlo con confianza.
• Migración que empieza de cero. Cambiar de proveedor debería significar continuar lo que ya existe, no reconstruir todo desde el principio porque nadie más puede trabajar sobre ese código.
• Seguridad que no puedes revisar. Sin acceso al código fuente, no puedes auditar la seguridad de tu propio sistema y si algo falla, tampoco puedes reaccionar sin depender de un tercero.

Señales de alerta antes de firmar

• El contrato no menciona explícitamente de quién es el código.
• No se contempla la entrega de documentación técnica.
• No existe una cláusula que defina qué pasa si la relación termina.
• El proveedor no acepta que un tercero audite el código.
• Todo el conocimiento técnico del proyecto está en una sola persona del equipo proveedor.

Lo que deberías exigir antes de empezar

• Cesión total de la propiedad intelectual, con cláusula explícita de que el código, los diseños y la documentación pasan a ser tuyos al cierre del proyecto.
• Repositorio a tu nombre desde el primer commit, no en una cuenta del proveedor a la que solo él tiene acceso.
• Documentación técnica como entregable, no como algo que «si sobra tiempo, se hace» arquitectura, decisiones técnicas y cómo desplegar el sistema.
• Un plan de salida definido en el contrato, no negociado en medio de un conflicto: qué pasa si decides cambiar de proveedor y  en qué condiciones.

En PyP Soft trabajamos bajo este mismo criterio: el código, la documentación y el conocimiento del proyecto son tuyos, no un activo que quede atado a nosotros. Si en algún momento decides continuar con otro equipo, deberías poder hacerlo sin que eso dependa de nuestra buena voluntad.

Sobre la propiedad legal del código en Perú

En Perú, el software está protegido por el Decreto Legislativo N° 822 (Ley sobre el Derecho de Autor). Lo importante para ti como cliente: no asumas un default legal a tu favor asegúrate de que el contrato especifique explícitamente que la propiedad del código te corresponde a ti, no lo dejes a interpretación.

Preguntas que deberías hacerle a cualquier proveedor antes de firmar

Preguntas que deberías hacerle a cualquier proveedor antes de firmar

• ¿El código es mío desde el inicio o  solo después del pago final?
• ¿Puedo auditarlo con un equipo técnico externo si lo necesito?
• ¿La documentación técnica está incluida como entregable del proyecto?
• ¿Qué pasa si decido cambiar de proveedor más adelante?

Preguntas frecuentes

Si no tienes claro en qué condiciones está construido tu sistema actual o  estás por firmar un proyecto nuevo, hablemos antes de que firmes cualquier cosa.