Una agencia cierra, un contrato termina en malos términos, o la única persona que entendía el sistema simplemente se va — y una empresa descubre, en el peor momento posible, que nunca tuvo realmente las llaves de lo que pagó. Esto no es un caso límite raro; es el resultado previsible de no preguntar nunca, al principio de una relación, qué pasa con todo si esa relación termina.
El acceso es lo primero que hay que resolver, no lo último
Quién tiene el registro del dominio, la cuenta de alojamiento, el repositorio del código fuente, las claves de API de terceros de las que depende el sistema — y si esas cuentas están a nombre de la propia empresa o de la agencia, con la empresa como invitada. Esta pregunta es fácil y ligeramente incómoda de hacer antes de firmar un contrato, y muy difícil y muy costosa de resolver después de que una relación ya se haya deteriorado. La respuesta correcta, en casi todos los casos, es que la propiedad principal de cada cuenta recae en la empresa, con la agencia recibiendo acceso para hacer el trabajo — no al revés.
La propiedad del código es una cuestión concreta y contractual
"Lo construimos, así que lo poseemos hasta que nos paguéis por entregarlo" es un modelo de negocio legítimo para algunas agencias, y un problema serio si una empresa no se dio cuenta de que ese era el acuerdo que aceptaba. El contrato debe indicar claramente, por escrito, quién posee el código y los activos resultantes, si esa propiedad es inmediata o depende del pago final, y qué pasa con esa propiedad si el contrato termina antes de tiempo — un lenguaje vago aquí no es un descuido, a menudo es exactamente la ambigüedad de la que dependerá más tarde un traspaso difícil.
La documentación es lo que hace que la propiedad sea realmente utilizable
Poseer código que nadie puede leer se parece bastante a no poseer nada. Un sistema sin documentación de su arquitectura, sus variables de entorno, su proceso de despliegue y sus decisiones clave es, en la práctica, solo operable por quien lo construyó — lo que significa que la empresa no ha reducido realmente su dependencia de la agencia por el mero hecho de tener los archivos, solo ha hecho que esa dependencia sea más difícil de ver. Exigir documentación básica de traspaso como entregable, no como extra opcional, es lo que convierte la propiedad técnica en independencia práctica.
La exportabilidad es la prueba que revela la dependencia real
Un sistema construido sobre herramientas propietarias que solo la agencia original puede operar, o sobre una plataforma que dificulta o imposibilita exportar datos y configuración, crea dependencia sin importar lo que diga el contrato sobre la propiedad. La prueba honesta es simple: ¿podría otro desarrollador competente hacerse cargo de este sistema y seguir trabajando en él en un plazo razonable, usando solo lo que se le ha entregado? — y si la respuesta es realmente incierta, esa incertidumbre merece resolverse antes de construir el sistema, no después de que se haya ido el desarrollador original.
Por qué es más barato resolver esto antes de la primera factura
Cada uno de estos términos es una negociación pequeña y tranquila al principio de una relación, y una negociación estresante y sin margen de maniobra después de que algo ya haya salido mal — pedir documentación de traspaso a una agencia todavía activamente implicada cuesta casi nada; pedírsela a una que ya se ha marchado cuesta muchísimo, si es que siquiera es posible.
Esto se sitúa junto a la misma decisión de comprar, construir o configurar — la elección técnica correcta solo sigue siendo correcta si la empresa puede realmente seguir operando el sistema sin importar quién lo construyó.
Nuestro equipo de software entrega la propiedad completa, la documentación y sistemas exportables como estándar, no como un extra negociado — porque un cliente que podría irse limpiamente, y elige quedarse, es el único tipo de relación que merece la pena tener.
