Cómo hacer copia de seguridad de un proyecto hecho con IA

Exporta el código a un repositorio de GitHub bajo tu cuenta y guarda aparte los datos, que viven en tu proyecto de Supabase. Son dos copias distintas porque son dos cosas distintas: el código es la aplicación y los datos son lo que la gente ha escrito dentro. Una sin la otra no restaura nada.

Casi todo el mundo hace la primera y se olvida de la segunda. El código se puede volver a generar; los pedidos, los usuarios registrados y los mensajes recibidos no.

¿Qué hay que copiar exactamente?

Un proyecto publicado no es un solo archivo, sino cuatro cosas que viven en sitios diferentes. La tabla dice qué es cada una, dónde está y quién se encarga de conservarla.

La columna que importa es la tercera. Exportar el código resuelve una fila y solo una, y aun así es el paso más valioso porque es el que hace que el proyecto siga existiendo si dejas de usar la herramienta.

¿Por qué el export a GitHub es la copia principal?

Porque produce un repositorio normal bajo tu cuenta, no un archivo comprimido dentro de un producto ajeno. Se puede clonar, leer, modificar y volver a desplegar con las herramientas de siempre, y el proyecto te pertenece.

La diferencia con guardar una página suelta es grande. Un archivo HTML descargado se puede abrir; un repositorio con su código, su configuración y su lista de dependencias se puede instalar, cambiar y reconstruir. Solo lo segundo es una copia de seguridad de verdad.

Hay además un efecto secundario útil: un repositorio guarda la historia. Cada envío de cambios deja un punto al que volver, así que una tanda de ediciones que estropea algo deja de ser un problema irreversible y pasa a ser un paso atrás.

¿Cuándo conviene exportar?

Hay cuatro momentos en los que sale claramente a cuenta, y uno en el que no.

Antes de una tanda de cambios arriesgada. Rediseñar la portada, reestructurar la navegación o rehacer la sección de precios son buenos momentos para tener una foto del estado anterior.

Cuando el proyecto entra en una relación con un cliente. Si alguien te paga por esto, la propiedad tiene que ser visible, y un repositorio a su nombre o al tuyo lo demuestra sin discusión.

Cuando va a entrar alguien técnico. Un repositorio es el formato de entrega que cualquier desarrollador conoce, y evita la conversación incómoda de aprender una herramienta ajena antes de tocar nada.

Antes de publicar de verdad. Una copia del estado que sí funcionaba es la póliza más barata que existe.

El momento en el que no compensa es la fase de exploración pura, cuando la forma del proyecto cambia cada día. Ahí mantener dos copias solo divide la atención entre versiones que se separan solas.

¿Cómo se copian los datos, que es lo que no se regenera?

Desde Supabase, porque ahí es donde viven. Supabase aporta base de datos, registro de usuarios y almacenamiento de archivos, y es un proyecto de tu cuenta, así que las herramientas de copia y restauración son las suyas.

La regla mental es simple: si un humano lo escribió, no se puede regenerar. Un formulario de contacto con doscientos mensajes, una lista de usuarios registrados o un histórico de pedidos son datos únicos. El código que los muestra se puede volver a construir por 6 créditos; los datos no se pueden volver a construir por ningún precio.

Los pagos son el caso tranquilo: si cobras con Stripe, los clientes, las suscripciones y el histórico ya viven en tu cuenta de Stripe y no dependen del sitio. Conviene saberlo para no duplicar esfuerzo donde no hace falta.

Anota también lo que no es un archivo: qué dominio usas, en qué registrador está y qué registros DNS apuntan a dónde. Cabe en media página y es justo lo que nadie recuerda el día que hace falta.

¿Cuánto cuesta mantener esta disciplina?

Casi nada, porque exportar y copiar datos no son acciones de construcción. Lo que cuesta créditos es generar y cambiar: una construcción son 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. En modo Hi-Fi, 12 y 6.

El plan gratuito trae 5 créditos, Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes. El detalle completo, con ejemplos de proyectos enteros, está en cuánto cuesta una web hecha con IA.

Merece la pena verlo al revés: como el gasto está en generar y no en extraer, tener copias es una decisión de disciplina y no de presupuesto. No hay ningún incentivo económico para no tenerlas.

¿Cómo se comprueba que la copia sirve?

Una copia que nunca se ha restaurado es una suposición, no una copia. La comprobación tarda menos que la duda.

Clona el repositorio en tu ordenador y arráncalo, aunque no sepas programar y solo quieras ver que levanta. Ese es el único experimento que responde de verdad a la pregunta de si el proyecto existe fuera de la herramienta.

Después hojea los archivos. No hace falta entender el código: hace falta ver que está, que la cantidad de archivos es razonable y que los nombres se corresponden con las secciones de tu proyecto. Comprueba de paso que no haya claves ni contraseñas de servicios dentro del repositorio, porque esa configuración es una cosa aparte del código.

Antes de entregarse, cada construcción se arranca en un entorno de pruebas, y una que no llega a abrirse se reporta como fallo en vez de entregarse. Eso baja el riesgo de guardar una copia de algo roto, no lo elimina, así que la prueba manual sigue valiendo la pena.

¿Dónde están los límites honestos de una copia?

Cuatro, y conviene conocerlos antes de confiar en ella.

Copiar no es restaurar. Tener el código y los datos no reconstruye solo el proyecto en marcha: hay que desplegar, reconectar servicios y volver a apuntar el dominio. Es trabajo, y conviene haberlo hecho una vez sin prisa.

Las dos copias se separan. En cuanto alguien cambia algo en el repositorio, la versión del constructor y la del repositorio dejan de ser el mismo proyecto. Elige cuál es la buena, y normalmente debería ser el repositorio.

El mantenimiento pasa a ti. Las dependencias envejecen, y después de exportar nadie las actualiza por ti.

La lógica muy específica sigue siendo trabajo. Restaurar el código no restaura las decisiones. Si algo raro se consiguió con varias ediciones, conviene tenerlo anotado en algún sitio legible.

Nada de esto es propio de las herramientas con IA: es lo que siempre ha significado tener software propio. Y para hacerlo no hace falta programar, como se explica en si hace falta saber programar. Construye algo pequeño, expórtalo y ábrelo tú mismo en zugo.dev: diez minutos dicen más que cualquier promesa de propiedad.