Lo que el lock-in cuesta de verdad a un fundador indie

El lock-in no es una cláusula que firmas y olvidas. Es la suma lenta de decisiones que, juntas, hacen que dejar a un proveedor sea más caro que quedarse — aunque suba precios, empeore el producto o elimine la función que necesitas. Para un fundador en solitario, el coste se traduce en semanas de migración sin cobrar, datos de clientes perdidos, integraciones rotas y una cola de soporte que nadie responde mientras reconstruyes.

Esta guía te da un checklist que puedes pasar a cualquier herramienta cloud, SaaS o IA antes de comprometerte, y una forma sencilla de estimar lo que te costaría irte.

Los cuatro vectores de lock-in que merece la pena revisar

Casi cualquier situación de lock-in viene de uno de estos cuatro vectores. Puntúa cada uno de 0 (nada) a 3 (severo) para cada herramienta que evalúes.

  1. Lock-in por API y runtime propietario. Código o configuración que solo funciona en un proveedor — una función serverless atada a un evento con forma propietaria, una consulta de base de datos que usa una extensión propietaria, un modelo IAM cableado a través del SDK de un único cloud. Cuanto más corta y estándar sea la interfaz, más seguro estás.
  2. Lock-in por formato y datos. Tarifas de egress, exports no portables, formatos de snapshot exclusivos del proveedor, o formatos “estándar” con extensiones propietarias encima. Pregunta si un dump normal de Postgres, un CSV o un JSON te permitiría moverte de verdad.
  3. Lock-in operativo. Tus runbooks, módulos de IaC, pipelines de CI, dashboards y hábitos de guardia construidos alrededor de un único ecosistema. Es la forma que los fundadores subestiman más, porque vive en la memoria muscular más que en el código.
  4. Lock-in contractual y comercial. Descuentos empaquetados que se desmoronan si dejas un producto, renovaciones automáticas, penalizaciones por salir y precios generosos a bajo volumen pero punitivos a escala.

Una herramienta que suma 0–4 entre los cuatro vectores es una elección cómoda. 5–8 significa que deberías negociar una salida limpia antes de firmar. 9 o más es una dependencia estructural: presupuesta la migración desde el día uno.

El checklist de 15 minutos antes de firmar

Aplica estas preguntas a cada candidato serio. Trata “no lo sé” como una respuesta que suspende.

Datos y exports

  • ¿Puedo exportar el dataset completo, incluyendo historial y auditoría, en un formato abierto y documentado?
  • ¿El export está automatizado por API o hay que abrir un ticket manual?
  • ¿Hay tarifas de egress por registro o por GB que tenga que presupuestar?
  • Si dejo de pagar, ¿cuánto tiempo mantengo acceso de lectura a mis datos?

APIs e integración

  • ¿La API pública está documentada, versionada y estable a lo largo de años?
  • ¿Puedo apuntar una herramienta competidora al mismo origen de datos, o tengo que reconstruir la integración?
  • ¿Webhooks, streams de eventos y proveedores de identidad (OIDC, SAML) son estándar?

Huella operativa

  • ¿Puedo reproducir mi configuración desde un script, o se hace a base de clics en la UI?
  • ¿Dashboards, logs y alertas son exportables, o están atrapados en la UI del proveedor?
  • ¿Cuánto del conocimiento de mi equipo es “dónde clicar” frente a “qué escribir”?

Términos contractuales

  • ¿Qué pasa con mis datos al terminar y en qué plazo?
  • ¿Hay renovaciones automáticas, permanencias mínimas o descuentos empaquetados que pierdo si dejo un producto?
  • ¿El pricing es público y escala de forma lineal, o da saltos en ciertos umbrales?

Si no puedes responder al menos 10 de estas preguntas desde la web y el contrato del proveedor, todavía no tienes información suficiente para decidir.

Un marco sencillo para calcular el coste de cambiar

Antes de firmar, escribe una página de plan de salida. No necesita ser detallada, pero obliga a clarificar. Usa esta plantilla:

  1. ¿Qué datos tendría que mover y en qué formato? (filas, GB, peculiaridades del esquema)
  2. ¿Qué código o configuración tendría que reescribir? (horas estimadas, no impresiones)
  3. ¿Qué integraciones se romperían y cómo las reconstruyo? (dependencias concretas, no categorías)
  4. ¿Qué ventana de downtime o servicio degradado verían mis clientes?
  5. ¿Cuánto costaría la migración en dinero, suponiendo que mi tiempo vale algo?

Si no puedes rellenar esto en una página, el lock-in es más profundo de lo que sugiere el marketing del proveedor. Una prueba útil, tomada de la práctica de gestión de activos IT: si tu equipo no puede describir la salida en una sola página — qué perderías, cuánto costaría, cuánto tardaría — tampoco tienes información suficiente para negociar con confianza, y mucho menos para firmar un compromiso plurianual.

Lock-in reversible vs. restrictivo: sabe en cuál estás

No todas las dependencias son iguales. Lock-in reversible significa que puedes irte con planificación: los datos son exportables en un formato utilizable, las integraciones se reconstruyen con esfuerzo razonable y el coste de salir es sobre todo tiempo interno. Lock-in restrictivo significa que los exports no están disponibles o son prohibitivamente caros, los términos del contrato hacen comercialmente irracional irse, o el producto está tan embebido que reemplazarlo implica un riesgo real de servicio.

La diferencia entre ambos se mide normalmente en meses frente a años de esfuerzo. La mayoría de fundadores en solitario nunca migrarán un lock-in restrictivo — simplemente seguirán pagando. Por eso el objetivo al firmar es asegurarte de que cada herramienta que adoptas vive firmemente en la columna reversible.

Deliberado, accidental o mutuo: ¿quién creó la dependencia?

El lock-in no siempre lo fabrica el proveedor. A veces es accidental: tu equipo construyó lógica a medida sobre una función propietaria porque era lo más rápido en ese momento. A veces es mutuo: ambas partes invirtieron en una integración cuya sustitución sería dolorosa. Entender quién creó la dependencia cambia cómo respondes. Lock-in deliberado es una negociación contractual. Lock-in accidental es una limpieza de arquitectura. Lock-in mutuo es una relación que gestionar, no un problema del que huir.

Patrones prácticos para mantenerte intercambiable

No necesitas evitar cada servicio propietario para estar a salvo. Lo que necesitas es mantener pequeño el radio de la explosión.

  • Envuelve cada proveedor en una interfaz interna. Un módulo fino en tu código que sea dueño de todas las llamadas a un único proveedor. Cuando cambies de proveedor, reescribes un fichero, no toda la aplicación.
  • Empareja herramientas con componentes, no con tendencias. Una herramienta por trabajo. La búsqueda busca. El email envía email. El hosting aloja. El sprawl crea la maleza que te ahoga después.
  • Prefiere formatos estándar sobre extensiones propietarias. Postgres estándar antes que un fork gestionado con tipos propietarios. Exports CSV estándar antes que dialectos JSON a medida. Siempre puedes subir de nivel más adelante; no siempre puedes bajar.
  • Mantén una copia exportable de tus datos más importantes, en una programación que tú controlas. Aunque el proveedor ofrezca exports, tener tu propia copia cambia la negociación.
  • Puntúa las herramientas por arquitectura, no por hype. Modularidad, auditabilidad e intercambiabilidad importan más que el brillo de la demo.

Cuándo el lock-in es la respuesta correcta

A veces la apuesta merece la pena. Una base de datos propietaria que te permite lanzar una funcionalidad seis meses antes, un servicio gestionado de IA que te ahorra un trimestre de ingeniería de ML, una plataforma low-code que permite a un único fundador operar un producto entero — son intercambios legítimos. El error es hacerlos sin saber el precio.

Si decides aceptar el lock-in, escribe esa decisión. Nombra al proveedor, la dependencia que aceptas, el detonante que te haría irte (subida de precio, aviso de sunset, incidente de seguridad) y el coste aproximado de salir. Un memorando de un párrafo, archivado junto al contrato, le gana a un año de arrepentimiento.

Preguntas frecuentes

¿Cuál es la mejor pregunta que puedes hacer a un proveedor SaaS sobre lock-in? “Si cancelo mañana, ¿en qué formato y en qué plazo recupero mis datos?” Si la respuesta es vaga, ya tienes tu respuesta.

¿Son las herramientas open source siempre más seguras frente al lock-in? No. Hacer self-hosting traslada el lock-in del proveedor a ti — el conocimiento operativo de tu equipo, tus scripts de migración, tu ruta de actualización. El open source elimina el lock-in comercial, pero no elimina por sí solo el lock-in técnico u operativo.

¿Cada cuánto debería revisar el riesgo de lock-in? En cada renovación y cada vez que una herramienta cruce un umbral de uso que cambie tu coste de cambio. Una vez al año como mínimo.

¿Cuál es el lock-in que los fundadores subestiman más? El operativo — los dashboards, runbooks y hábitos construidos alrededor de un único ecosistema. Parece gratis hasta el día que tienes que dejarlo.

Fuentes