Eso se llama vendor lock-in, y en desarrollo de software es mucho más común de lo que parece. No porque los proveedores actúen de mala fe necesariamente, sino porque el modelo de negocio de muchos está armado para que irse cueste caro.
Qué es exactamente
Vendor lock-in es la situación en la que una empresa depende tanto de un proveedor específico que cambiarlo implica un costo, un riesgo o una pérdida de funcionalidad desproporcionados — no por el valor del trabajo, sino por cómo quedó construido el sistema.
No es lo mismo que una relación comercial que funciona bien y por eso continúa. La diferencia está en si te quedaste porque el sistema es bueno, o porque irte te obligaría a reconstruir todo desde cero.
Las formas más comunes en que aparece
Código que no es tuyo hasta el último pago (o nunca)
El repositorio vive en la cuenta del proveedor. Tenés un producto funcionando, pero no tenés acceso a construirlo, revisarlo o llevártelo.
Infraestructura a nombre del proveedor
Hosting, dominio, base de datos, servicios en la nube — todo registrado con las credenciales del proveedor, no las tuyas. El día que la relación termina, no es una migración: es empezar de cero.
Sin documentación
El sistema funciona, pero solo la persona que lo escribió sabe por qué. Si esa persona se va — del lado del proveedor o del tuyo — el conocimiento se va con ella.
Dependencias propietarias no estándar
Frameworks o herramientas de uso exclusivo del proveedor, elegidas no por ser la mejor solución técnica sino porque hacen que solo ellos puedan mantener el sistema después.
SaaS de terceros sin exportación de datos
Tu información vive en una herramienta de la que no podés sacarla en un formato usable. Técnicamente no es "tu proveedor" el que te tiene atado — es la plataforma que eligió sin pensar en la salida.
Por qué pasa
El incentivo suele estar mal alineado, no ser malintencionado. Ya lo escribimos hablando de precio fijo: cuando el modelo de negocio del proveedor depende de que sea difícil irse, retener el control técnico es una forma —a veces inconsciente— de asegurar continuidad. Cuantas más piezas del sistema dependen exclusivamente del proveedor, menos margen de negociación tiene el cliente en el futuro.
No hace falta mala fe para que esto pase. Hace falta, simplemente, que nadie del lado del cliente haya preguntado a tiempo "¿esto es mío?".
Las señales de que tenés vendor lock-in hoy
Si reconocés dos o más de estas señales, no significa que tengas que cambiar de proveedor mañana. Significa que vale la pena pedir acceso y documentación ahora, mientras la relación está bien.
No tenés acceso al repositorio de tu propio sistema.
El hosting, el dominio o la base de datos están a nombre del proveedor, no tuyo.
No existe documentación técnica — solo el conocimiento de quien lo construyó.
Cambiar de proveedor implicaría reconstruir el sistema desde cero, no migrarlo.
Dependés de una integración o librería que solo el proveedor original sabe operar.
Cómo se ve un proyecto sin lock-in
Repositorio en tu cuenta desde el día uno del proyecto, no al final.
Infraestructura (hosting, dominio, base de datos) registrada a tu nombre.
Documentación técnica que cualquier desarrollador nuevo pueda leer y entender.
Stack estándar y ampliamente soportado — no herramientas propietarias de nicho.
Capacitación al equipo incluida, no vendida aparte.
En BROTE trabajamos con arquitectura hexagonal justamente porque desacopla el dominio de la infraestructura: cambiar de proveedor de hosting, de pasarela de pago o incluso de base de datos no debería requerir reescribir el sistema. Si tu arquitectura obliga a eso, ese también es un síntoma de lock-in — aunque tengas el código en tu propia cuenta.
BROTE
¿Tu sistema es realmente tuyo?
Repositorio, infraestructura y documentación a tu nombre desde el primer día — sin excepciones ni letra chica. Es una condición del proyecto, no un extra.
Hablemos de tu sistema →