Constructor de apps con IA y GitHub: exportar el código

Sí, y esta es la integración que cambia la naturaleza del trato. Zugo exporta el código fuente de tu proyecto a tu repositorio de GitHub, y el proyecto te pertenece. A partir de ese momento tienes algo que un desarrollador puede abrir, leer y continuar sin depender de la herramienta que lo generó.

La pregunta detrás de esa función casi nunca es técnica. Es "¿qué pasa conmigo si dejo de pagar?", y merece una respuesta concreta en lugar de una promesa de marketing.

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

Significa que el proyecto deja de ser una fila en la base de datos de un proveedor y pasa a ser archivos en un repositorio que controlas tú. No es una descarga de una copia visual ni un paquete de HTML aplanado: es el código con el que se construye el proyecto.

Esa diferencia importa porque determina qué se puede hacer después. Con una exportación visual solo puedes mirar. Con el código puedes cambiar cualquier cosa, ejecutar el proyecto en tu máquina, ponerlo bajo control de versiones y desplegarlo donde quieras.

También cambia quién puede ayudarte. Un repositorio de GitHub es el formato universal del sector: cualquier desarrollador sabe qué hacer con él, sin tener que aprender antes una plataforma concreta. Eso amplía enormemente la lista de personas a las que puedes contratar el día que lo necesites.

¿Quién es el dueño del proyecto?

Tú. Es la respuesta corta y no tiene asteriscos que la maticen dentro del producto, pero conviene entender qué implica en la práctica.

El código exportado vive en tu cuenta de GitHub, bajo tu usuario u organización. Los permisos los das tú, y quitarlos también. Si mañana contratas a alguien, le das acceso al repositorio; si esa colaboración termina, se lo retiras y el proyecto sigue donde estaba.

Lo mismo aplica al resto de piezas si conectaste integraciones. Los datos viven en tu proyecto de Supabase, los cobros en tu cuenta de Stripe, el despliegue puede ir a tu cuenta de Vercel y el dominio está registrado a tu nombre. Sumado, eso significa que ninguna parte crítica del producto se queda dentro del constructor.

Una precisión honesta: propiedad no es lo mismo que mantenimiento. Que el código sea tuyo no lo vuelve automáticamente fácil de mantener para alguien que nunca lo ha visto. Es un punto de partida excelente, no un producto documentado por dentro.

¿Cuándo conviene exportar y cuándo no?

Depende de en qué fase está el proyecto, y equivocarse en esto cuesta tiempo en las dos direcciones.

Todavía no conviene exportar mientras el proyecto siga cambiando de forma cada semana. Iterar dentro del constructor es más rápido: una edición es una frase y cuesta 3 créditos, mientras que el mismo cambio hecho a mano cuesta el tiempo de alguien. Exportar pronto es pagar antes por una flexibilidad que aún no necesitas.

Conviene exportar cuando aparece al menos una de estas tres señales. La primera es lógica de negocio muy específica que llevas tres o cuatro ediciones intentando describir con palabras. La segunda es una integración que no está en la lista de conectores. La tercera es que vas a incorporar a un desarrollador de forma estable.

También conviene exportar por seguridad, aunque no vayas a tocar nada. Un repositorio con el estado actual del proyecto es una copia de respaldo real, y tenerla no obliga a usarla.

¿Qué puedes hacer una vez el código está en GitHub?

Cosas que dentro del constructor no tienen equivalente, y otras que sí lo tienen pero salen más caras fuera. Esta tabla ayuda a decidir dónde hacer cada cambio.

La lectura útil de la tabla no es "el código es superior". Es que el constructor gana en velocidad para los cambios frecuentes y el código gana en profundidad para los cambios raros. Muchos proyectos viven felices usando los dos en momentos distintos.

¿Qué no resuelve la exportación?

Tres cosas, y decirlas ahorra decepciones.

No te devuelve al constructor con los cambios hechos a mano. Cuando el código sale y un desarrollador lo modifica fuera, el proyecto tiene dos historias. Planifica el momento del cambio como una decisión, no como una puerta giratoria.

No convierte el proyecto en algo que se mantiene solo. Un repositorio necesita a alguien que actualice dependencias, revise avisos de seguridad y arregle lo que se rompa. Antes de exportar, eso lo hacía el constructor por ti.

No sustituye a un equipo de desarrollo. Zugo no reemplaza a un equipo en un producto complejo, y tener el código en GitHub no cambia el tamaño del producto: solo cambia quién puede trabajar en él.

¿Cuánto cuesta esto?

La exportación es una función del producto, y la generación es lo que se paga en créditos. Estos son los números vigentes.

Doscientos créditos equivalen a unas 33 construcciones rápidas o 16 plataformas completas. La cuenta que suele salir mejor es la obvia: agota primero el ciclo barato de ediciones dentro del constructor y exporta cuando ese ciclo deje de avanzar, no antes.

Lo que se paga fuera son otras cosas: la cuenta de GitHub según su propio plan, el hosting si despliegas por tu cuenta y, sobre todo, las horas del desarrollador que continúe el trabajo. Ese último es el gasto grande y el que hay que planificar de verdad.

¿Cómo encaja GitHub con las demás integraciones?

GitHub cubre el código y Vercel cubre el despliegue, así que se usan juntos con frecuencia. El código sale a tu repositorio y el proyecto se sirve desde tu cuenta de hosting, con lo que ni la fuente ni la ejecución dependen ya del constructor.

Supabase completa el cuadro por el lado de los datos. Si el proyecto tiene usuarios, esos usuarios y sus registros viven en tu proyecto de Supabase desde el principio, no dentro de Zugo. Sumar código propio, hosting propio y datos propios es lo que en la práctica significa independencia.

Stripe, Resend, Google Analytics y el dominio propio siguen la misma lógica: cada uno es una cuenta tuya con un servicio externo. La herramienta escribe la conexión, tú conservas la relación comercial.

¿Qué hacer ahora?

Construye la primera versión dentro del constructor y afínala con ediciones hasta que la forma del producto deje de cambiar. Es el tramo donde la generación aporta más y donde el código aporta menos.

Cuando llegues a un límite concreto y no a una sensación general, exporta y sigue con un desarrollador. Para decidir el momento ayudan puedo exportar el código, puedo contratar a un desarrollador después y puedo vender lo que construyo. Puedes empezar a construir y ver hasta dónde llega el ciclo de ediciones en zugo.dev, con 25 plantillas listas de las que 5 son de juegos.