Toda herramienta de vibe coding con un botón de GitHub repite alguna versión de la misma frase: “eres dueño de tu código, sin lock-in.” Aparece en la página de precios, en las preguntas frecuentes, normalmente justo al lado de un icono de check. Trata esa frase como una afirmación que hay que verificar, no como un hecho que hay que aceptar, porque la brecha entre “puedes exportar un archivo” y “puedes irte” es donde vive la mayor parte del lock-in real.
Lo que la “exportación” calla discretamente
Una base de código no es una sola cosa. Es un frontend, un backend y una base de datos, y una herramienta puede anunciar “exportación de código” refiriéndose solo al primero de los tres. Base44 documenta esta división con claridad: el código fuente del frontend se exporta a GitHub, pero la lógica de backend está alojada y gestionada por completo en la infraestructura propia de Base44, descrita en sus propios materiales como no se puede modificar ni exportar directamente. Las reseñas de Base44 en Product Hunt confirman el mismo patrón desde el lado del usuario: la base de datos y el backend quedan atrapados en la infraestructura cerrada de la plataforma aunque el frontend salga limpiamente. Un usuario de Reddit que intentó realmente salir de la plataforma reportó que le cotizaron un año del plan Builder de 40 $/mes, 480 $, solo para acceder a los archivos fuente después de que su aplicación fallara repetidamente en un bucle de depuración.
Zite evita la pregunta por completo. No ofrece ninguna vía de sincronización con GitHub ni exportación de código alguna, algo que sus propios usuarios señalan en Reddit como un obstáculo real llegado el momento de una migración o del traspaso a un desarrollador. Sin botón de exportación, la conversación sobre “eres dueño de tu código” ni siquiera empieza.
Código exportado que no quieres
La otra mitad de la ilusión es asumir que el código exportado es código que alguien elegiría mantener. Lovable exporta genuinamente React y TypeScript estándar, y sincroniza con GitHub para el desarrollo local, lo cual es una fortaleza real. Pero los propios reportes de sus usuarios describen el resultado como desordenado y poco escalable: un creador lo resumió diciendo que servía como referencia visual pero no como algo que se pudiera portar limpiamente, recomendando que un desarrollador reconstruya la aplicación en un stack real en lugar de heredar la generada. Esto es coherente con el patrón más amplio que este sitio sigue: el bucle de corrección deja atrás funciones utilitarias duplicadas y estilos parcheados, porque el modelo no puede ver toda la base de código que está editando. La exportación te entrega ese parcheado con una URL de GitHub adjunta, no una base de código que un nuevo desarrollador pueda retomar desde el primer día.
El lado de la base de datos agrava el problema. Usuarios de Lovable en Reddit han llamado a la plataforma “Hotel California” para tu base de datos: puedes entrar, pero varios reportes describen a la IA iniciando de forma autónoma una migración de backend, desde el proyecto Supabase privado de un creador hacia el Supabase gestionado propio de Lovable, sin consentimiento explícito. Sea cual sea el aspecto de la exportación del frontend, el backend y su esquema son un proyecto de migración aparte, uno que diseñó la IA y que el creador quizás nunca revisó por completo.
Las herramientas que hacen esto bien, y lo que ese “bien” cuesta
Bolt y v0 son los contraejemplos honestos, y merece la pena nombrarlos como tales. Bolt documenta descarga directa de la base de código junto con sincronización automática con GitHub que produce una base de código React/Vite estándar sin formatos propietarios. Los propios materiales de v0 describen las exportaciones como código React y TypeScript limpio e inspeccionable, sin capas propietarias ni mecanismos de bloqueo. Ambas afirmaciones se acercan más a lo que debería significar “sin lock-in”: lo que sale de la plataforma es lo que realmente querrías seguir desarrollando.
Pero fíjate en lo que esa honestidad no elimina. Una exportación limpia sigue entregándote una base de código escrita por un modelo con una ventana de contexto limitada, todavía sujeta al problema del segundo día: funciona hoy, y que sobreviva a seis meses de cambios reales depende de si alguien revisa lo que contiene. El código portable es necesario para evitar el lock-in. No es suficiente para evitar la factura de mantenimiento.
La pregunta debajo del check
Antes de confiar en una afirmación de exportación, tres preguntas separan el marketing de la realidad. Primero, qué sale realmente: solo el frontend, o el backend y la base de datos junto con él. Segundo, quién puede leerlo sin la ayuda de la herramienta, porque un código que nadie del equipo puede mantener es portable solo de nombre. Tercero, qué reportaron los creadores que lo intentaron, porque un hilo de Reddit sobre una tarifa de salida de 480 $ te dice más que un check en una página de precios.
Para aplicaciones de negocio, portales, herramientas internas, CRMs, existe una forma estructural de esquivar toda la cuestión: construir donde la “exportación” no sea código en primer lugar. En Softr, la autenticación, los permisos y la estructura de datos son configuración de la plataforma, y los datos subyacentes pueden vivir en fuentes que ya controlas (Airtable, Google Sheets o SQL) o accederse a través de la propia base de datos de Softr mediante API y MCP, de modo que un creador no depende de una exportación a GitHub para evitar depender de la infraestructura de un solo proveedor. Es un intercambio distinto a la propiedad del código, no un sustituto: cambias “puedo exportar el código” por “los datos nunca estuvieron atrapados desde el principio.” Qué intercambio es el correcto depende de si la aplicación necesita un desarrollador que sea dueño de lógica personalizada, el caso de Cursor o Bolt, o si simplemente necesita funcionar sin uno.