¿Puedo exportar el código de un builder con IA? Sí

Sí. Zugo exporta el código fuente del proyecto generado a un repositorio de GitHub en tu cuenta, y el proyecto es tuyo. Con el código no viajan las cosas que nunca fueron código: el historial del chat, los créditos, el alojamiento en zugo.run y las cuentas de los conectores, que ya eran tuyas desde el principio.

Esa separación es la parte útil de la respuesta. La pregunta "¿puedo llevarme el código?" es en realidad la pregunta "¿qué me queda si dejo de usar esta herramienta?", y merece una respuesta detallada.

¿Qué significa exactamente "exportar el código"?

Es la operación que deja el código fuente completo del proyecto generado en un repositorio que gestionas tú. El resultado se parece a cualquier proyecto: archivos fuente, configuración y lista de dependencias, suficiente para clonarlo y arrancarlo con herramientas estándar.

Conviene distinguir exportar el código de descargar una página. Un archivo HTML guardado desde una vista previa no es lo mismo que un proyecto que se puede instalar, modificar y volver a construir. Es esa segunda posibilidad la que convierte al generador en un punto de partida y no en una parada final.

De paso cambia el nivel de riesgo de usar la herramienta. Un proyecto que solo existe dentro del producto de otro depende de sus precios, sus planes y su continuidad. Un repositorio en tu cuenta sobrevive a las tres cosas, y ese es el significado práctico de la palabra "propiedad".

¿Qué acaba exactamente dentro del repositorio?

El proyecto tal cual, ordenado como un desarrollador espera encontrarlo: archivos fuente, configuración y manifiesto de dependencias. Nada se minifica ni se ofusca por el camino, porque es el mismo código con el que funcionaba la construcción.

Conviene ajustar las expectativas sobre el alcance. La exportación es la aplicación, no tu infraestructura. Si la construcción habla con Supabase, el código de esas llamadas está en el repositorio, y el proyecto de Supabase sigue viviendo en tu cuenta de Supabase, exactamente donde estaba.

La tabla se lee mejor como tranquilidad que como lista de carencias. Casi todo lo de la columna "no" o bien ya está bajo tu control en otra cuenta, o bien es el registro de cómo se hizo algo y no la cosa en sí.

¿Hay que pagar para llevarse el propio código?

La exportación no está montada como un peaje de salida. Los planes compran generación, y la forma de ese precio importa más que cualquier número suelto: Free incluye 5 créditos una sola vez, Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes.

Los créditos se gastan en acciones. Una construcción cuesta 6 créditos, una edición 3, y una plataforma multipágina 12 por las tres primeras páginas más 3 por cada página adicional. El modo Hi-Fi duplica construcción y edición: 12 y 6.

Por qué esto viene al caso: la parte cara de cualquier generador es generar, no extraer. Si sacar tu propio código tuviera un precio creciente aparte, la afirmación de propiedad sería decorativa.

La cuenta honesta se hace por proyecto y no por mes. Una landing que construyes una vez y exportas son unos pocos créditos. Una plataforma que afinas durante dos semanas es sobre todo ediciones, y 200 créditos dan 66 ediciones si solo gastas en eso.

¿Qué hacer con el repositorio en la primera hora?

Cuatro cosas, y llevan menos tiempo del que cuesta leer sobre ellas.

Primero: clónalo y arráncalo en local. No para cambiar nada, sino para confirmar que el proyecto se levanta fuera del generador. Es la única comprobación que responde de verdad a la pregunta sobre propiedad.

Segundo: hojea los archivos aunque no programes. No necesitas entender el código, necesitas ver que existe, que la cantidad de archivos es razonable y que los nombres se corresponden con las secciones de tu proyecto.

Tercero: comprueba que no hay claves ni contraseñas de conectores dentro del repositorio. Las credenciales de servicios externos son una cosa aparte del código, y en un repositorio abierto no pintan nada.

Cuarto: decide dónde vive la verdad a partir de ahora. Si alguien empieza a subir cambios al repositorio, ese repositorio pasa a ser la fuente única, porque lo que hagas después en el builder queda en otra copia y nadie las reconcilia. El traspaso completo está en si un desarrollador puede retomarlo después.

¿Y si no sé programar? ¿Sirve de algo exportar?

Sirve, y por tres motivos que no exigen leer una línea de código. El primero es la salida: si un día quieres cambiar de herramienta o contratar a alguien, existe algo que entregar, y no hay que reconstruir desde cero.

El segundo es la negociación. Un desarrollador que recibe un repositorio funcionando presupuesta cambios sobre algo concreto, no sobre una descripción. Eso suele reducir el presupuesto y siempre reduce los malentendidos.

El tercero es la copia de seguridad. Un repositorio es una copia del proyecto en un sitio que controlas tú, independiente de cualquier cuenta que puedas perder. Merece hacerlo aunque no pienses tocarlo nunca. El detalle del conector está en la guía de GitHub.

Lo que no deberías esperar es entender el proyecto por haberlo exportado. Abrir el repositorio no enseña a programar, y una carpeta de archivos con nombres desconocidos puede intimidar sin motivo. Trátalo como el contrato de tu piso: no lo lees a diario, pero quieres tenerlo tú y no que lo guarde otro.

Tampoco hace falta hacerlo el primer día. Un experimento que quizá abandones el jueves no necesita repositorio. En cuanto el proyecto empiece a recibir visitas reales, o a cobrar dinero real, ya no es un experimento y sí lo necesita.

¿Cuáles son los límites honestos de la exportación?

Tres, y decirlos evita sorpresas. El primero: lo que sale es el código de la aplicación, no un producto listo para operar. Alojarlo, configurar variables de entorno y desplegarlo son tareas que pasan a ser tuyas, aunque Vercel esté entre los conectores y sea la ruta corta.

El segundo: el código exportado es un punto de partida honesto, no un proyecto revisado por un equipo. Si va a sostener un negocio real, que lo lea alguien con oficio. Zugo no sustituye a un equipo de desarrollo en un producto complejo, y esa frase es igual de cierta después de exportar que antes.

El tercero: una vez fuera, las mejoras las haces fuera. Editar en el builder cuesta 3 créditos y editar en el repositorio cuesta tiempo de desarrollo; lo que no funciona es hacer las dos cosas a la vez y esperar que se unan solas.

Si vas a construir algo que importe, exporta pronto y no cuando haya un problema. Empieza el proyecto en Zugo, publícalo, y en cuanto tenga forma manda el código a tu GitHub. El resto de la copia de seguridad, la de los datos, está en cómo hacer copias de seguridad.