¿Qué es el vendor lock-in en desarrollo de software? (y cómo evitarlo al contratar un equipo externo)

El vendor lock-in en desarrollo de software es la dependencia de un proveedor externo tan fuerte que cambiarlo —o directamente dejar de usarlo— sale carísimo, tarda meses o no es viable. Pasa cuando el código, la documentación o el conocimiento del proyecto quedan atrapados del lado del proveedor en vez de quedar del lado de la empresa que pagó por ellos. No es un riesgo exclusivo de la nube: aparece cada vez que se contrata desarrollo externo sin definir, desde el principio, quién es dueño de qué.

¿Qué causa el vendor lock-in al contratar desarrollo externo?

Casi nunca es una jugada deliberada del proveedor: es el resultado de contratos que no especifican propiedad intelectual, herramientas internas que solo el proveedor sabe operar, y documentación que vive en la cabeza de un puñado de personas en vez de en un repositorio. En la mayoría de las jurisdicciones, por defecto, el código pertenece a quien lo escribió —no a quien lo pagó— salvo que el contrato incluya una cesión explícita de propiedad intelectual ('work made for hire'). Sin esa cláusula, pagar por el desarrollo no te convierte automáticamente en dueño de lo que se construyó.

El lock-in aparece en tres formas distintas y se suelen dar juntas: técnica (frameworks o infraestructura propietaria sin equivalente estándar), legal (propiedad intelectual sin ceder explícitamente en el contrato) y de conocimiento (documentación que nunca se escribió porque siempre hubo alguien del proveedor disponible para explicarlo de nuevo). Las tres se notan el mismo día: el día que hay que migrar.

¿Cuáles son las señales de que ya estás en vendor lock-in?

• No tenés acceso de administrador a los repositorios, dominios o cuentas de terceros del proyecto — el proveedor sí.
• La documentación técnica no existe por escrito, o existe pero está desactualizada respecto de lo que corre en producción.
• El proyecto depende de una herramienta o framework propietario del proveedor sin un equivalente estándar disponible en el mercado.
• Nadie en la empresa puede estimar, ni siquiera aproximadamente, cuánto tardaría y cuánto costaría migrar a otro proveedor.

¿Qué tan preocupante es la dependencia de un proveedor en 2026?

Más de lo que la mayoría asume, incluso entre empresas que ya vieron venir el problema. Una encuesta de Zapier a 542 ejecutivos C-level de EE. UU. con contrato pago activo con al menos un proveedor de IA encontró que el 81% está al menos algo preocupado por la dependencia de su organización de proveedores específicos —un 29% dice estar muy preocupado— y para el 47% el impacto sería serio: al menos una función clave del negocio dejaría de funcionar si su proveedor principal desapareciera de un día para el otro (Zapier, 2026).

El dato más incómodo es la brecha entre lo que las empresas creen que pueden hacer y lo que efectivamente logran: el 89% de esos mismos ejecutivos cree que podría cambiar de proveedor en cuatro semanas, pero entre el 66% que ya lo intentó, el 58% dice que la migración falló directamente o le tomó mucho más esfuerzo del esperado (Zapier, 2026). La dependencia de un proveedor no se nota leyendo el contrato del día uno: se nota el día que hay que salir.

¿Por qué el costo ya no es la única variable al elegir un proveedor externo?

Porque las empresas ya aprendieron, a los golpes, que el proveedor más barato del día uno puede ser el más caro el día que hay que irse. Según la Encuesta Global de Outsourcing 2024 de Deloitte, el costo como principal motivo para tercerizar cayó del 70% al 34% de las empresas encuestadas: la relación con el proveedor y su forma de gestionarla pasaron a pesar tanto o más que la tarifa por hora.

¿Cómo se evita el vendor lock-in al contratar desarrollo externo?

• Cesión explícita de propiedad intelectual en el contrato, sin un genérico 'el cliente es dueño del entregable' que no especifica si incluye repos, credenciales, cuentas de terceros y diagramas de arquitectura.
• Código en el repositorio de la empresa desde el primer commit, no en uno del proveedor que se transfiere 'al final'.
• Documentación como entregable exigible por milestone, no como una tarea que se posterga hasta que ya no queda tiempo para hacerla bien.
• Evitar herramientas o frameworks propietarios del proveedor cuando no hay una alternativa estándar disponible si hay que migrar.
• Elegir un equipo con historial de entregas verificable en vez de una relación que se volvió indefinida porque nadie definió cuándo o cómo termina.

¿Cómo estructura Zenit un modelo que no dependa de un proveedor fijo?

Un squad de Zenit no es una relación indefinida con un proveedor único: es un equipo que se contrata por proyecto, con criterios de aceptación firmados por milestone y evidencia de GitHub verificable en cada entrega —el código y su historial de commits quedan documentados desde el primer día, no recién cuando el proyecto termina.

Y si un squad no puede seguir, el proyecto no vuelve a foja cero: el Squad B backup de Zenit toma el contexto ya documentado —brief, decisiones, código, historial de commits— en vez de que la empresa tenga que reconstruirlo de memoria con un proveedor nuevo.

Cada squad, además, entra a la red con un historial de entregas verificado —no autodeclarado— antes de que exista tu proyecto, así que la decisión de con quién trabajar no depende de referencias armadas para la ocasión.

El vendor lock-in no se evita desconfiando de todo proveedor externo. Se evita eligiendo un modelo donde la propiedad, la documentación y la continuidad del proyecto no dependen de que un proveedor puntual siga disponible —y Kaizen arma ese match entendiendo el proyecto real antes de recomendar un equipo.