Constructor de apps con IA y Vercel: desplegar en tu cuenta

Sí. Vercel es la integración de despliegue de Zugo y sirve para publicar el proyecto en tu propia cuenta de hosting en lugar de dejarlo solo en tu-slug.zugo.run. La cuenta es tuya y se paga aparte. Conectarla no gasta créditos, porque los créditos pagan la generación, no la publicación.

Ahora la pregunta útil, que casi nadie se hace en el orden correcto: ¿necesitas esto ya o todavía no?

¿Qué diferencia hay entre publicar en zugo.run y desplegar en Vercel?

Las dos vías dejan el proyecto accesible en internet. Lo que cambia es de quién es la infraestructura y quién se ocupa de ella.

La lectura de la tabla no es que una vía sea mejor. Es que resuelven fases distintas. Mientras el proyecto cambia cada dos días, el ciclo corto del constructor gana claramente. Cuando el proyecto se estabiliza y entra gente técnica, mover el despliegue empieza a tener sentido.

¿Cuándo merece la pena desplegar por tu cuenta?

Cuando aparece una razón concreta, no cuando aparece la sensación de que "es más profesional".

Merece la pena si vas a incorporar a un desarrollador de forma estable. A partir de ese momento el equipo quiere ramas, vistas previas por rama y control del proceso de publicación, y todo eso vive del lado del hosting propio.

Merece la pena si necesitas algo que no forma parte del proyecto generado: variables de entorno propias, una función de servidor a medida, una integración que no está entre los conectores disponibles. Esas cosas se añaden en el código, y el código desplegado tiene que estar donde tú puedas tocarlo.

Merece la pena si tienes requisitos de tu organización sobre dónde y bajo qué contrato se aloja el servicio. Es una razón administrativa, no técnica, y es perfectamente válida.

No merece la pena todavía si tu proyecto es una página de aterrizaje que sigues reescribiendo, un portafolio o una prueba de una idea. Mover el despliegue añade una pieza que mantener y no acelera nada de lo que estás haciendo ahora.

¿Qué mantenimiento asumes al mover el despliegue?

Cuatro responsabilidades que antes no eran tuyas y pasan a serlo. Merece la pena verlas antes de decidir, no después.

Las dependencias del proyecto envejecen. Alguien tiene que actualizarlas y comprobar que nada se rompe al hacerlo. Es trabajo pequeño y recurrente, y desatendido durante un año deja de ser pequeño.

Los avisos de seguridad hay que leerlos. Un proyecto con paquetes desactualizados no falla de golpe: falla el día que alguien encuentra el hueco.

Los fallos de despliegue son tuyos. Si una publicación falla a las nueve de la noche, no hay nadie más mirando. Con el flujo del constructor, una construcción que no abre no se entrega, y ese filtro deja de aplicarse cuando el despliegue se hace fuera.

La configuración se documenta o se olvida. Variables de entorno, claves y ajustes propios se acumulan, y seis meses después nadie recuerda por qué estaba ese valor ahí. Escríbelo mientras lo configuras.

¿Cómo encaja Vercel con GitHub?

Se usan juntos con mucha frecuencia porque cubren mitades complementarias del mismo movimiento.

GitHub cubre el código: la exportación deja el proyecto en tu repositorio, con histórico de versiones y permisos que gestionas tú. Vercel cubre la ejecución: sirve el proyecto desde tu cuenta con tu configuración.

Juntos responden a la pregunta que hay detrás de casi todas las dudas sobre constructores: qué pasa si dejo de pagar. Con el código en tu repositorio, los datos en tu proyecto de Supabase, los cobros en tu Stripe y el despliegue en tu Vercel, no queda ninguna pieza crítica dentro del constructor.

También conviene entender la contrapartida. En cuanto un desarrollador modifica el código fuera, el proyecto tiene dos historias: la del constructor y la del repositorio. Ese es un cambio de fase deliberado, no una puerta por la que se entra y se sale.

¿Qué se rompe con más frecuencia en el traslado?

Tres cosas, y ninguna tiene que ver con la calidad del código generado.

Las variables de entorno que no se copiaron. Claves de servicios externos que existían en un sitio y no en el otro. El síntoma es un proyecto que carga y falla justo en la función que usa el servicio.

El dominio apuntando al sitio anterior. Si conectaste tu dominio antes de mover el despliegue, hay que actualizar los registros DNS. Y como la propagación tarda, durante un rato verás el proyecto viejo y creerás que el traslado falló.

La confusión sobre qué versión es la buena. Editas en el constructor, no vuelves a desplegar, y el cambio no aparece en la dirección definitiva. Decide qué origen manda y comunícalo a quien trabaje contigo.

¿Cuánto cuesta esto?

Hay dos facturas distintas y conviene no mezclarlas.

Los créditos pagan la generación dentro de Zugo. Una construcción cuesta 6 créditos, una edición 3, una plataforma multipágina 12 por las tres primeras páginas y 3 por cada página adicional. El modo Hi-Fi cuesta el doble: 12 y 6. El plan gratuito da 5 créditos, Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes. Publicar en tu-slug.zugo.run y conectar Vercel no consumen créditos.

Vercel se paga a Vercel según el plan que elijas, y esa relación es tuya. Sumado al coste del dominio y al de cualquier otro servicio externo, ese es el gasto que crece cuando montas la infraestructura por tu cuenta.

El coste que no aparece en ninguna factura es el tiempo de mantenimiento de la lista anterior. Para un proyecto pequeño suele ser el argumento decisivo a favor de quedarse en el flujo simple una temporada más.

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

Tres, dichos claros.

Desplegar en tu cuenta no mejora el proyecto. Mueve la responsabilidad de sitio. Un proyecto lento o mal estructurado sigue siéndolo en cualquier hosting.

Zugo no sustituye a un equipo de desarrollo en un producto complejo, y tener el despliegue propio es normalmente la señal de que ese equipo ya hace falta. La lógica de negocio muy específica se afina con ediciones sucesivas hasta cierto punto, y después con código.

La comprobación en entorno de pruebas se aplica a lo que entrega el constructor. Verifica que la construcción arranca antes de dártela. No cubre lo que ocurra en tu propio proceso de despliegue después.

¿Qué hacer ahora?

Quédate en el flujo simple mientras el proyecto siga cambiando de forma. Publica en .zugo.run, conecta tu dominio cuando el contenido esté firme y mide con analítica antes de tocar la infraestructura.

Cuando llegue una razón concreta de las de la lista, exporta el código y despliega en tu cuenta. Para preparar ese momento, constructor de apps con IA y GitHub cubre la exportación, cómo publicar tu proyecto explica el paso a producción y puedo contratar a un desarrollador después trata el relevo con un equipo. Puedes empezar en zugo.dev y decidir la infraestructura cuando el proyecto la pida.