Vendor lock-in en apps hechas con IA: qué pasa si Lovable, Bolt o v0 suben el precio o cierran

Montaste tu app con Lovable, Bolt o v0. Funciona, la usas cada día y pagas una cuota mensual a la plataforma. Hasta ahí, bien. Pero un día te haces la pregunta incómoda: ¿y si mañana triplican el precio? ¿Y si la empresa cierra, o cambia las condiciones de un mes para otro? ¿Me quedo sin app y sin los datos, o puedo coger todo y llevármelo a otro sitio?

Es una duda sensata, y poca gente la resuelve antes de que sea urgente. La respuesta corta es que no dependes de la herramienta tanto como crees, pero sí de tres decisiones que casi nadie mira al empezar. Vamos a verlas, para que sepas en qué situación estás hoy y qué puedes hacer esta misma semana.

¿Qué es exactamente lo que te ata a una de estas herramientas?

Lo primero es separar dos cosas que se confunden todo el rato. Una es la herramienta que escribe la app: el editor con IA donde le dices lo que quieres y te va montando pantallas. Esa la usas mientras construyes. La otra es dónde vive la app una vez hecha: dónde corre para que la gente la use, y dónde se guardan los datos.

El editor es lo de menos a largo plazo. Puedes construir con Lovable hoy y no volver a abrirlo nunca: si el código ya está hecho y lo tienes, la app sigue funcionando sin la herramienta. Lo que de verdad importa es la segunda parte. Y ahí es donde muchos, sin saberlo, dejan todo dentro de la plataforma —código, base de datos y dirección web— porque es el camino que la herramienta pone por defecto. Ese es el nudo del vendor lock-in: no que uses una herramienta, sino que todo lo tuyo viva solo dentro de ella.

Las tres cosas que deciden si estás atado

No hay que ser técnico para saber en qué situación estás. Se reduce a tres elementos, y cada uno puede estar de tu lado o del lado del proveedor:

Cuando los tres son tuyos, la herramienta es intercambiable: si suben el precio, te mudas y ya. Cuando los tres viven solo en el proveedor, estás en sus manos, y el día que cambie las reglas te toca aceptar o empezar casi de cero.

Si no sabes en cuál de las dos columnas estás, esa es exactamente la primera pregunta que resolvemos antes de tocar nada: mándanos el enlace de tu app y te decimos qué es tuyo y qué está atado, sin compromiso y antes de hablar de arreglar nada.

Cómo saber hoy en qué situación estás

Sin mirar código, con tres comprobaciones:

• ¿Tienes el código en algún sitio que no sea la propia herramienta? Busca si tu proyecto está conectado a un repositorio (GitHub suele ser el nombre) o si en algún momento descargaste un archivo con el código. Si la respuesta es "solo está dentro de Lovable/Bolt", ahí tienes el primer punto flojo.
• ¿Dónde se guardan los datos de tus clientes? Si al montar la app creaste una cuenta aparte en un servicio de base de datos (Supabase es el más habitual con estas herramientas), la tienes tú. Si nunca creaste nada y "simplemente funciona", probablemente vive dentro de la plataforma.
• ¿Quién registró el dominio? Si entras a tu cuenta del registrador (donde pagas el .com o el .es) y ahí está, es tuyo. Si tu web va bajo una dirección del tipo tuapp.laplataforma.app, todavía no tienes dominio propio.

Traducido a decisión rápida:

• Los tres son tuyos → no estás atado; cambiar de herramienta es una tarde de trabajo, no un drama.
• Tienes el código pero la base de datos está dentro → medio atado; lo movible es fácil, sacar los datos es lo que lleva tiempo.
• No tienes copia de nada → atado del todo; conviene ponerle remedio antes de que haya una razón urgente, no después.

Un caso con números

Pongamos un caso inventado para que se vea la lógica. Una consulta con tres profesionales monta con Bolt una app de citas y fichas de pacientes. Funciona, y pagan unos 30 € al mes por el plan de la plataforma. Todo cómodo, hasta que a los seis meses el proveedor anuncia que el plan que usan sube a 90 € al mes y que ciertas funciones pasan a un plan superior.

Escenario A: nunca sacaron el código ni movieron los datos. Sus opciones son tragar con la subida o empezar casi de cero en otro sitio, volviendo a montar la app y a meter las fichas a mano. Lo segundo puede costar semanas y varios miles de euros —no porque la app sea complicada, sino porque hay que reconstruir lo que ya tenían.

Escenario B: al montarla, alguien dejó el código conectado a un repositorio propio y la base de datos en una cuenta a su nombre. Ante la misma subida, mueven la app a un hosting normal por unos pocos euros al mes y siguen igual. El trabajo de la mudanza: cuestión de horas, no de semanas.

Son cifras de ejemplo para ilustrar la diferencia, no una tarifa. Lo que no cambia es de dónde sale esa diferencia: no de la herramienta, sino de tres decisiones que se toman —o no— al principio.

Qué hacer para no quedarte atrapado

Si vas a empezar una app con una de estas herramientas, o si ya tienes una y quieres asegurarte, la receta es corta:

• Conecta el código a tu propio repositorio desde el día uno. La mayoría de estas herramientas lo permiten (buscar la opción de "conectar con GitHub" o "exportar código"). Así siempre tienes una copia fuera, hagan lo que hagan.
• Pon la base de datos en un servicio a tu nombre, no dentro de la cuenta del proveedor ni de un freelance. Que la cuenta la controles tú es lo que hace que los datos sean tuyos de verdad.
• Registra el dominio tú, en tu propia cuenta de registrador. Es barato y te lo llevas a donde quieras.
• Si te lo construye otra persona, pregúntale estas mismas tres cosas antes de empezar. De quién es el código, dónde van los datos y a nombre de quién queda el dominio. Un buen proveedor te lo deja todo a tu nombre sin que se lo pidas; si esquiva la pregunta, es mala señal —el mismo tipo de mala señal que conviene detectar antes de firmar cualquier desarrollo.

Ninguna de estas cosas te obliga a saber programar. Son decisiones de a-nombre-de-quién, no de código.

Cuándo merece la pena que lo mire alguien

Si tienes una app hecha con IA en marcha y no sabes responder a "¿tengo yo el código y los datos?", ese es justo el momento de mirarlo, mientras no hay urgencia. Sacar una app de una plataforma antes de que suban el precio es un trabajo tranquilo; hacerlo el día que cambian las condiciones, con el negocio funcionando encima, es otra historia. Y si de paso la app tiene otros puntos débiles —como que se cae cuando llega tráfico de verdad o que los datos estén más a la vista de lo que crees—, es buen momento para verlo todo junto.

Si quieres que alguien mire tu app y te diga qué es tuyo, qué está atado y qué haría falta para soltarlo, mándanos el enlace y te lo decimos con un diagnóstico claro antes de tocar nada. Si prefieres escribir directamente: contact@easybyte.es.