Vendor lock-in: cuánto cuesta y cuándo conviene aceptarlo

El vendor lock-in no es un defecto que haya que evitar. Toda herramienta que adoptas te vende velocidad hoy a cambio de opcionalidad mañana, y el trabajo consiste en ponerle precio a ese intercambio antes de firmar.

Un fundador de logística con el que trabajamos había construido todo el portal de operaciones de su empresa en una plataforma no-code. Seis semanas de trabajo, y funcionó muy bien durante dos años. Entonces su mayor prospecto puso single sign-on y un registro de auditoría exportable en el contrato, como condición para firmar. La plataforma no hacía ni una cosa ni la otra. Reconstruirlo llevó cinco meses, y el cliente no esperó.

El vendor lock-in es la condición de depender tanto de un proveedor que irse cuesta más que quedarse, incluso cuando quedarse es lo incorrecto. No es un defecto oculto en las malas herramientas. Es el subproducto natural de cualquier herramienta que hace trabajo real por ti, y se acumula en cuatro sitios: tu código, tus datos, tus flujos de trabajo y tu gente.

Ese fundador no quedó atrapado por tomar una mala decisión. Quedó atrapado por tomar una buena decisión y no volver nunca a revisar su precio.

Qué significa realmente el vendor lock-in

La definición de manual habla de costes de cambio: formatos propietarios, APIs incompatibles, penalizaciones contractuales, el gasto de migrar de un proveedor a otro. Esa definición es correcta y casi inútil, porque describe una condición que se aplica literalmente a todas las herramientas que adoptarás en tu vida.

La distinción útil es otra.

No estás atrapado cuando irse es caro. Estás atrapado cuando irse es lo bastante caro como para que dejes de planteártelo.

Esa es la línea que importa. Un coste de cambio es un número. El lock-in es lo que ocurre cuando ese número se vuelve tan grande que empieza a tomar decisiones por ti: cuando dejas de evaluar alternativas, cuando rodeas una funcionalidad que falta en lugar de exigirla, cuando le dices que no a un cliente porque tu plataforma dijo que no primero. El fundador de logística no decidió perder ese contrato. Su stack decidió por él, dos años antes, un martes cualquiera, cuando nadie estaba mirando.

Los cuatro cerrojos

El lock-in suele discutirse como si fuera una sola cosa. Son cuatro, y tienen precios muy distintos.

Cerrojo de código. No puedes llevarte el software, porque no hay software que llevarse. Las plataformas no-code son el caso más puro: no hay artefacto, no hay repositorio, no hay nada que se ejecute en ningún sitio fuera del editor del proveedor. Los lenguajes propietarios son la misma trampa con traje. En el momento en que tu lógica vive en un dialecto que solo una empresa compila, esa lógica es suya.

Cerrojo de datos. Todas las plataformas del mundo exportan tus datos. Casi ninguna exporta su forma. Recibes un CSV de clientes y pierdes las relaciones entre ellos, el modelo de permisos, la máquina de estados por la que pasan los pedidos, los IDs a los que hacen referencia otros tres sistemas. Las filas sobreviven. El significado no.

Cerrojo de procesos. Este es el que nadie valora, y suele ser el más caro. A lo largo de dos años tu equipo remodela silenciosamente el negocio para que encaje en los supuestos de la herramienta. Alguien inventa un paso manual porque la plataforma no puede dar uno real. Ese paso se vuelve costumbre, la costumbre se vuelve proceso, y el proceso se vuelve la forma en que funciona la empresa. Ya no estás migrando un software. Estás migrando una organización.

Cerrojo de personas. Las únicas personas capaces de mantener eso están certificadas en el ecosistema del proveedor, lo que significa que contratas de un mercado laboral que el proveedor controla, a un precio que el proveedor influye. Cuando tu único desarrollador certificado se va, no acudes al mercado. Acudes al directorio de partners del proveedor.

El cerrojo de código es el más ruidoso y el más fácil de arreglar. Los cerrojos de procesos y de personas son silenciosos, acumulan intereses cada día, y son los que de verdad atrapan a las empresas.

El lock-in es un precio, no un defecto

Aquí está la parte que el resto de internet no entiende.

Toda abstracción que adoptas te ata. Postgres te ata. React te ata. Tu software de contabilidad, tu proveedor de nóminas, el lenguaje en el que está escrito tu producto, la nube donde corren tus servidores. La única manera de no tener ninguna dependencia es construirlo todo tú mismo, que es otra trampa, y bastante peor.

Así que la pregunta nunca es “¿estoy atrapado?”. Lo estás. La pregunta es cuánto pagaste y si lo que compraste lo vale.

Joel Spolsky trazó la línea hace veinticinco años en In Defense of Not-Invented-Here Syndrome, y no se ha movido desde entonces:

Si es una función central del negocio — hazlo tú mismo, cueste lo que cueste.

Ese es el framework completo, y se traduce limpiamente en una regla sobre dependencias. El lock-in en una función que no genera dinero es barato, y deberías darle la bienvenida. No quieres ser dueño de tu sistema de nóminas. Átate al proveedor y duerme tranquilo. El lock-in en el sistema del que depende tu margen es existencial, y ningún descuento es lo bastante grande para justificarlo. Si tu motor de precios, tu algoritmo de emparejamiento o tu lógica de riesgo viven dentro del producto de otra empresa, no diriges una empresa. Diriges una franquicia.

La mayoría de los fundadores lo hace al revés. Agonizan sobre qué CRM comprar, una decisión reversible en tres semanas, y luego dejan despreocupadamente que aquello que los diferencia se construya dentro de una plataforma de la que nunca escaparán. La decisión entre build y buy no va de coste. Va de en qué lado de esa línea se sitúa el sistema.

La prueba del coste de salida

Antes de adoptar cualquier cosa que vaya a tocar un flujo central, hacemos cuatro preguntas. Lleva veinte minutos y es el seguro más barato que existe en software.

1. Si nos vamos dentro de dieciocho meses, ¿qué se viene físicamente con nosotros?

Nombra los artefactos en voz alta: código fuente, esquema de base de datos, datos, documentación, dominio, registros de clientes, integraciones. Escribe la lista. Si la respuesta honesta es “un CSV”, no eres un cliente. Eres un inquilino.

2. ¿Cuántas semanas, no cuántos euros?

Ponle precio a la salida en semanas de ingeniería y en interrupción del negocio, nunca en cuotas de licencia. El dinero se recupera. Una reconstrucción de cinco meses que aterriza en mitad de una ronda, no. El coste de salida del fundador de logística no era una cifra en una factura. Era un trimestre y un logo de peso.

3. ¿Nuestro roadmap necesita el permiso de su roadmap?

Esta es la más afilada de las cuatro. Si no puedes lanzar una funcionalidad que te diferencia hasta que el proveedor decida construirla, no has comprado una herramienta. Has subcontratado tu estrategia de producto a una empresa que nunca ha hablado con tus clientes y a la que le da igual si ganas.

4. ¿Quién más puede mantener esto?

Si la respuesta es “los partners certificados del proveedor”, tienes un problema de oferta disfrazado de decisión técnica. Si la respuesta es “cualquier ingeniero competente que conozca este lenguaje”, estás bien.

Puntúa las cuatro con honestidad. Una herramienta que suspende las preguntas 1 y 3 es excelente para validar y peligrosa como arquitectura. Eso no es una contradicción. Es un calendario.

Dónde se quedan atrapados los fundadores de verdad

Busca vendor lock-in y encontrarás diez artículos sobre las tarifas de salida de AWS y la estrategia multicloud. Útiles, si tienes un departamento de TI. No es ahí donde muerde a un fundador. Muerde aquí.

La plataforma no-code que se te quedó pequeña. Te llevó a un producto funcionando en seis semanas, que fue la decisión correcta. No puede hacer SSO, ni registros de auditoría, ni un modelo de permisos de verdad, ni el único flujo que tu cliente corporativo exige. La mayoría de los fundadores se quedan en no-code entre seis y doce meses de más, y ese retraso no es un fallo tecnológico. Es el fallo de no haber releído la etiqueta del precio cuando la empresa cambió.

La software house que se queda con tu repositorio. Esta es la que mata empresas, y casi siempre se descubre en el peor momento posible. Si tu contrato de desarrollo de software no dice que el código es tuyo, en un repositorio que tú controlas, desde el primer día, entonces no tienes un socio tecnológico. Tienes un casero. El source code escrow existe precisamente porque esto pasa lo bastante a menudo como para haber generado su propio instrumento jurídico.

El modelo de datos torcido alrededor de un solo proveedor. Alguien usó los IDs de una pasarela de pago como claves primarias. Alguien guardó el estado de un pedido en un campo que solo escribe ese proveedor. Dos años después, cambiar de pasarela significa reescribir el sistema de pedidos, y el sistema de pedidos es la empresa.

La herramienta interna que nadie documentó. Un colaborador la construyó, un colaborador la entendía, y ese colaborador ya no está. Ahora no estás atado a un proveedor. Estás atado a un sistema legacy con cero personas en plantilla.

Cuándo el lock-in es el intercambio correcto

A menudo. Más a menudo de lo que sugieren los artículos alarmistas.

Cuando aún estás validando. Si la empresa puede no existir dentro de un año, la opcionalidad es un artículo de lujo que no te puedes permitir. Átate fuerte, lanza en seis semanas y averigua si alguien quiere eso. La opcionalidad que nunca ejerces es dinero quemado.

Cuando la función no es central. Nóminas, correo, contabilidad, el CRM que usa tu equipo comercial de seis personas. Adopta al líder del mercado, átate y no vuelvas a pensar en ello. La carga mental de mantenerte portable en una commodity ya es, en sí misma, un coste.

Cuando la salida es genuinamente reversible. Si puedes irte en menos de cuatro semanas, eso no es lock-in. Es un coste de cambio, y los costes de cambio son normales.

Lo que nos deja con la regla práctica que usamos, y la única frase de este artículo que merece la pena escribir en una pizarra:

Acepta el lock-in en proporción inversa a la cercanía entre el sistema y tu margen.

Cuanto más lejos esté un sistema del dinero, más lock-in deberías aceptar de buen grado. Cuanto más se acerque, más deberías ser dueño. Casi todos los errores caros que nos llaman a arreglar son una violación de esa única línea.

Cómo evitar el vendor lock-in sin volverse paranoico

El fallo contrario existe, y es más común entre equipos técnicos que entre fundadores: construir capas de abstracción “por si acaso”, escribir tu propio wrapper alrededor de cada servicio, rechazar infraestructura gestionada porque algún día quizá te muevas. Eso es un impuesto de portabilidad, y lo pagas todos los días por una migración que probablemente nunca ocurrirá. El coste de la portabilidad prematura es un alquiler. El coste de una migración es una hipoteca. El alquiler es peor.

La versión proporcionada es corta.

Sé dueño del repositorio, desde el primer día, en una cuenta que tú controlas. Sé dueño de tu modelo de datos, y entiéndelo lo bastante bien como para describirlo en una frase. Sé dueño del dominio y del DNS. Exporta tus datos cada mes y, al menos una vez, restaura de verdad esa exportación en otro sitio. Una exportación que nunca has restaurado no es una copia de seguridad. Es una creencia.

Luego ponlo en el contrato: propiedad del código desde el primer día, cláusula de portabilidad de datos, y documentación como entregable con nombre, no como favor.

Los reguladores han empezado a tratar los costes de cambio como un problema de competencia y no como un inconveniente técnico. La Data Act de la Unión Europea, en aplicación desde septiembre de 2025, establece un marco que obliga a los proveedores de servicios de procesamiento de datos a permitir que sus clientes cambien de proveedor, y prohíbe las cláusulas contractuales que bloquean la portabilidad de datos. La dirección es clara: el derecho a irse se está convirtiendo en algo que se te debe, no en algo que negocias. Es una buena noticia, y llegará demasiado tarde para ayudarte con el proveedor que estás eligiendo este trimestre.

Preguntas frecuentes

¿Qué es el vendor lock-in, en términos simples?

Depender tanto de un proveedor que cambiarse costaría más que quedarse, incluso cuando quedarse te está haciendo daño. El coste puede estar en código que no puedes llevarte, datos que no puedes exportar de forma útil, procesos construidos alrededor de los límites de la herramienta, o personal que solo conoce el ecosistema de ese proveedor.

¿Cuál es un ejemplo de vendor lock-in?

Una startup construye su portal de operaciones en una plataforma no-code. Dos años después, un cliente corporativo exige single sign-on y un registro de auditoría. La plataforma no ofrece ninguno de los dos, no hay código fuente que modificar, y el único camino es una reconstrucción de cinco meses. El coste de cambio era invisible el día uno y decisivo el día setecientos.

¿Cómo se evita el vendor lock-in?

No se evita. Se le pone precio. Antes de adoptar una herramienta, pregunta qué se va físicamente contigo si te marchas, cuántas semanas llevaría la salida, si tu roadmap depende del roadmap del proveedor, y quién aparte de sus partners puede mantenerlo. Después, sé dueño del repositorio, del modelo de datos y del dominio, y prueba tus exportaciones.

¿El vendor lock-in siempre es malo?

No. El lock-in en una función commodity es un buen intercambio y normalmente una ganga. El lock-in en el sistema que produce tu margen es un error estratégico. La distancia entre el sistema y tus ingresos es lo que determina cuál de los dos tienes delante.

El fundador de logística reconstruyó su portal. Cinco meses, y perdió al cliente. Cuando le preguntamos qué haría diferente, no dijo que se habría saltado la plataforma no-code. Dijo que habría escrito en un papel, el día que la adoptó, cuánto costaría irse.

Nunca escribió ese número, así que creció en silencio durante dos años, y acabó descubriéndolo el único día en que no se podía pagar.

El lock-in nunca fue el problema. No conocer el precio, sí.