Haz una lista de todo lo que tu proyecto no podría dejar de usar mañana sin romperse. El proveedor donde vive, la base de datos, el servicio de autenticación, el de correo, el de pagos, el de archivos. No hace falta que sea exhaustiva: con ocho o diez líneas basta.
Esa lista es el inventario de tus ataduras, y casi nunca se escribe. Las decisiones que la componen se tomaron de a una, en semanas distintas, cada una razonable por su cuenta. Juntas definen cuánto cuesta cambiar de opinión, que es de lo que trata este artículo.
La dependencia de un proveedor concreto hasta el punto de que cambiarlo exige un trabajo desproporcionado frente al beneficio de cambiar.
No es un estado de sí o no. Es una escala, y la única medida que importa es el costo de salida: cuánto tiempo y dinero tomaría mover el sistema a otra parte si tuvieras que hacerlo.
La pregunta no es si estás atado, es cuánto cuesta soltarte
Todo proyecto está atado a algo. Usar PostgreSQL ata a PostgreSQL, escribir en Python ata a Python, y alojar en cualquier sitio ata a ese sitio. La independencia total no existe, y perseguirla produce sistemas llenos de capas de abstracción que solo sirven para hacer más lento el desarrollo de hoy a cambio de una migración que probablemente nunca ocurra.
El planteamiento útil es otro. Para cada dependencia hay una cifra: las semanas de trabajo que costaría reemplazarla. Mientras esa cifra sea conocida y proporcionada, la atadura es una decisión de negocio como cualquier otra. Cuando nadie la ha calculado, deja de ser una decisión y pasa a ser una sorpresa esperando su momento.
Esto importa especialmente cuando el código lo propone una IA. Un asistente sugiere el servicio que más aparece en su material de entrenamiento, y esa sugerencia llega sin la cifra. Nunca dice esto te ata durante tres años y salir cuesta dos meses, porque no se le preguntó y porque no conoce tu contexto.
Los cuatro niveles de atadura
No todas las dependencias pesan igual, y confundirlas es lo que lleva a proteger lo barato mientras se regala lo caro.
Una librería vive dentro de tu código y se reemplaza leyendo documentación. Un servicio gestionado como el de correo o el de pagos vive fuera, pero habla un lenguaje parecido al de sus competidores, así que cambiarlo es reescribir una parte acotada y volver a probarla.
La base de datos propietaria ya es otra cosa, porque no se va sola: arrastra el modelo de datos, las consultas y las suposiciones sobre cómo se comporta. Y la lógica de negocio dentro de la plataforma, cuando las reglas de permisos, los flujos y las validaciones solo existen en la consola de un proveedor, no se migra. Se vuelve a escribir desde cero, con la dificultad añadida de que nadie documentó nunca lo que hacía.
Cuándo la atadura es un buen negocio
Hay casos donde depender de un proveedor es claramente la decisión correcta, y conviene decirlo porque la conversación sobre lock-in tiende a un purismo que sale caro.
- Cuando el problema es difícil y no es tuyo. Procesar pagos, enviar correo que no acabe en spam o gestionar identidades son problemas con años de complejidad acumulada. Resolverlos internamente para evitar una atadura es cambiar dos semanas de integración por años de mantenimiento.
- Cuando el costo de salida es proporcional. Si reemplazar el servicio de correo toma una semana, la atadura es irrelevante: se decide el día que haga falta, sin drama.
- Cuando lo que se gana es tiempo de salida al mercado. Un proyecto que todavía no sabe si tendrá usuarios se juega su futuro en llegar, no en ser portable. La portabilidad es un costo que se paga hoy por una opción que se ejerce después, y muchas veces ese después no llega.
El patrón común es que la dependencia queda contenida en un borde del sistema. El resto del código no sabe qué proveedor hay detrás, porque habla con una función propia que podría estar respaldada por cualquiera.
Cuándo es una trampa
La atadura se vuelve un problema cuando cruza de los bordes hacia el centro. Tres señales concretas:
Los datos no salen completos. Es la más grave y la más fácil de comprobar. Si el proveedor ofrece exportar, pero solo el contenido y no las relaciones, o entrega un formato que solo su propio producto lee, tus datos no son portables aunque técnicamente puedas descargarlos.
Las reglas viven en la consola, no en el repositorio. Cuando el comportamiento del sistema se configura haciendo clic en paneles, no hay historial, no hay revisión y no hay forma de reconstruirlo en otro sitio. Es también el motivo por el que nadie recuerda por qué una regla está ahí.
El precio no depende de ti. Si la factura escala con algo que no controlas, y salir cuesta meses, el proveedor tiene margen para subir precios sabiendo que la alternativa es peor. No es una hipótesis malintencionada: es la posición natural de quien vende cuando el cliente no puede irse.
La pregunta no es si confías en el proveedor hoy. Es qué pasa si dentro de tres años cambia de dueño, de precios o de rumbo.
Dónde está el límite, dependencia por dependencia
La misma decisión cambia de signo según qué se esté atando. Esta es la lectura práctica de los casos más frecuentes en un proyecto pequeño o mediano.
| Qué atas | Qué se llevaría el proveedor | Costo de salida | Veredicto |
|---|---|---|---|
| Correo transaccional | Plantillas y estadísticas de envío | Días | Átate sin pensarlo |
| Pasarela de pagos | Historial y métodos guardados | Semanas | Aceptable, prevé la portabilidad del historial |
| Almacenamiento de archivos | Los archivos, si no hay copia | Semanas | Aceptable con copias propias |
| Autenticación | Usuarios y contraseñas cifradas | Semanas o meses | Verifica antes que puedes exportar usuarios |
| Base de datos propietaria | Modelo de datos y consultas | Meses | Decide con cuidado, es difícil de revertir |
| Reglas de negocio en la plataforma | El comportamiento del sistema | Reescritura | Evítalo, esto sí es la trampa |
La prueba que resuelve la duda en una tarde
Hay una verificación que vale más que cualquier promesa de portabilidad, y casi nadie la hace hasta que la necesita con urgencia.
Exporta tus datos. Hoy, con el proyecto funcionando. No leas la documentación sobre la exportación: ejecútala, descarga el archivo y ábrelo.
Que el archivo contiene los datos completos y no solo una parte. Que las relaciones entre registros siguen ahí y no se perdieron al aplanar el resultado. Que el formato lo puede leer algo que no sea el producto del proveedor.
Y que el proceso termina: muchas exportaciones funcionan con datos de prueba y fallan por tiempo de espera con el volumen real.
Si la exportación funciona y los datos están completos, tu costo de salida es alto pero finito. Si no funciona, acabas de descubrir tu dependencia más cara, y lo hiciste en un día tranquilo en lugar de durante una migración de emergencia.
Conviene repetirlo cada cierto tiempo y guardar el resultado. Una exportación que funcionó hace dos años no dice nada sobre la de hoy.
La atadura que no aparece en ningún contrato
Hay una quinta forma de dependencia que no sale en los diagramas porque no es técnica: lo que el equipo sabe hacer.
Después de dos años con un proveedor, la gente conoce sus rarezas, sus mensajes de error y los tres sitios donde hay que mirar cuando algo falla. Ese conocimiento no se exporta. Cambiar de proveedor significa volver a ser principiante en la parte del sistema que más rápido hay que arreglar cuando se rompe, y es la razón por la que muchas migraciones técnicamente viables no se hacen nunca.
No es un argumento para quedarse quieto, sino un costo que debe entrar en la cuenta. Una migración que parece de seis semanas de trabajo suele traer detrás varios meses en los que el equipo diagnostica más lento que antes.
En proyectos donde buena parte del código lo escribió una IA, esta atadura llega antes y pesa más. Si nadie del equipo entendió del todo cómo se integró el proveedor, no hay conocimiento que trasladar: hay que reconstruirlo desde el código antes siquiera de empezar a migrar.
Lo que cuesta de verdad cambiar de proveedor
Las estimaciones de migración fallan casi siempre por el mismo motivo: se calcula el trabajo de reescribir las llamadas y se olvida todo lo demás.
El reparto varía según el caso, pero la proporción se repite. Y explica por qué conviene que la parte cara esté resuelta de antemano: si los datos se exportan bien y hay copias propias, la migración se acerca a ese 20% que sí se sabe estimar.
Por eso la decisión sobre el nivel de atadura no se toma el día de la migración. Se toma mucho antes, cada vez que se integra algo nuevo y se decide si pasa por un solo punto del código o se reparte por todas partes.
Qué hacer sin sobre-diseñar
La reacción habitual al entender todo esto es construir capas de abstracción sobre cada proveedor, por si acaso. Es un error caro: se paga complejidad permanente por una flexibilidad hipotética, y las abstracciones prematuras casi siempre resultan equivocadas cuando llega la migración real, porque se diseñaron sin conocer al reemplazo.
Tres medidas cubren la mayor parte del riesgo sin ese costo:
- Contén cada proveedor en un punto del código. No una arquitectura de adaptadores: una función o un archivo por el que pasen todas las llamadas a ese servicio. Es prácticamente gratis al escribirlo y convierte una migración en un trabajo localizable.
- Mantén copias de los datos fuera del proveedor. Si los datos viven solo donde el proveedor los guarda, la atadura es total independientemente de lo que diga el contrato.
- Escribe la decisión cuando la tomes. Dos líneas: qué elegiste, qué alternativas había y qué costaría cambiar. Es lo que evita que dentro de dos años nadie recuerde si esa dependencia se eligió por un motivo o porque apareció primero.
Esa última medida es la que más rinde cuando parte del código lo escribe una IA. El asistente no recuerda por qué se eligió un proveedor, así que si la razón no está escrita, la próxima decisión relacionada se tomará sin ella.
Cómo plantearlo al pedir código
Si le vas a pedir a un modelo que integre un servicio, la diferencia entre una respuesta útil y una que te ata sin avisar está en una frase añadida al prompt.
En lugar de pedir la integración a secas, pide que el proveedor quede aislado en un punto y que te diga qué partes de su propuesta son específicas de ese proveedor y cuáles funcionarían con cualquier otro. Esa segunda parte es la que rara vez aparece sin pedirla, y es justamente la lista que necesitarías el día de la migración.
Y antes de aceptar la sugerencia, hazte la pregunta que cierra el tema: si este proveedor duplicara su precio el año que viene, ¿qué haría yo? Si la respuesta es pagar, porque no hay alternativa, la atadura dejó de ser una decisión hace tiempo.