Evitar el lock-in de proveedor: cómo ser dueño de tu software desde el primer día
La mayoría de los equipos revisa la cláusula de propiedad del contrato y se queda ahí. El contrato importa, pero el lock-in casi nunca es una cláusula de licencia. En la práctica es código al que no puedes acceder, entornos que nadie sabe reconstruir y conocimiento que vive en la cabeza de una persona del proveedor.
Si el proyecto terminara mañana, ¿podría tu equipo (o un proveedor nuevo) ejecutar, cambiar y volver a desplegar el sistema sin llamar a nadie? Si la respuesta honesta es no, todavía no eres dueño del sistema. Eres dueño de una factura.
Dónde se esconde realmente el lock-in
El repositorio. Si el código vive en la organización de GitHub del proveedor y al final recibes un zip, tienes una foto, no un sistema. El historial, los issues, las discusiones de review y la configuración de CI se quedan del otro lado.
Los entornos. Un sistema que solo se despliega desde el portátil de un ingeniero está bloqueado aunque tengas el código. La infraestructura que solo existe como clics manuales en una consola no la puede reconstruir nadie más.
Las credenciales. Claves de API, DNS, cuentas cloud y servicios externos registrados con el email del proveedor son el bloqueo práctico más común cuando una relación termina.
El conocimiento. Las decisiones tomadas en un hilo de chat y nunca documentadas son una dependencia de la memoria de una persona. Esa persona cambia de trabajo y el porqué de media arquitectura se va con ella.
La checklist que hace real la propiedad
1. Tu repositorio desde el primer día. El proveedor trabaja en un repo propiedad de tu organización, con tus permisos de administrador, desde el primer commit. Ni un espejo, ni una transferencia al final.
2. Cesión por escrito. El SOW cede todo el código fuente, la configuración de infraestructura y la documentación con el pago final, sin licencias de vuelta ni cuotas por usuario.
3. Un entorno reproducible, verificado. Un comando documentado (o un script corto) levanta el sistema en local y en una cuenta cloud nueva. Verifícalo durante el proyecto, no después.
4. Cuentas a tu nombre. Cloud, DNS, pagos, monitorización y cada clave de API registradas en tu organización, con el proveedor como miembro que puedes eliminar.
5. Registros de decisiones. Notas breves de por qué se eligieron el stack, el modelo de datos y los trade-offs. Una página por decisión es suficiente.
6. Escrow o un respaldo con nombre. En proyectos largos, el depósito del código fuente (escrow) o un contratista de respaldo designado elimina la pregunta del bus factor antes de que la haga tu equipo legal.
Cómo se ve esto en un proyecto sano
Nada de esto es hostil. Un proveedor que quiere ganarse el siguiente proyecto no tiene motivos para secuestrar el actual. En Urbano DX cada proyecto empieza en el repositorio del cliente, la entrega documentada de traspaso forma parte del alcance, y «un ingeniero nuevo puede continuar desde el README» se trata como criterio de aceptación, no como un favor.
La prueba es simple: pregunta a tu proveedor qué pasa si dejáis de trabajar juntos el mes que viene. Una respuesta concreta y segura es buena señal. Una vaga es el principio del lock-in.
Si estás definiendo un proyecto y quieres garantías de propiedad en el SOW desde el inicio, así están escritos nuestros paquetes.