¿Puedo colaborar con otra persona en un proyecto con IA?
Sí, aunque no compartiendo un cursor. En Zugo se colabora con lo que produce cada construcción: una dirección publicada que cualquiera abre, un repositorio de GitHub al que puedes añadir gente y tus propias cuentas de Supabase, Stripe y Vercel. Una persona escribe los prompts y el resto revisa y devuelve cambios por escrito.
Es un flujo real y, para dos o tres personas, suele ser más rápido que un lienzo compartido. También es distinto de lo que la mayoría imagina al preguntar, así que conviene decir qué funciona bien, qué te toca organizar y dónde se acaba el método.
¿Qué significa "colaborar" en este contexto?
Detrás de esa palabra hay tres cosas con tres respuestas distintas. Editar el mismo proyecto a la vez, en la misma ventana, es la versión que la gente imagina. Revisar el trabajo de otro y pedir cambios es la versión que los equipos hacen todos los días. Asumir el proyecto entero es la tercera.
Zugo responde a las tres en orden inverso al que se preguntan. El traspaso es lo más sólido: el proyecto es tuyo, el código se exporta a GitHub y cada conector funciona en tu propia cuenta. La revisión es fácil, porque cada proyecto se publica en una dirección tipo tu-slug.zugo.run y cualquiera con el enlace lo abre desde cualquier dispositivo.
La edición simultánea es lo que no hace, y decirlo sin rodeos ahorra una semana de confusión. No hay cursor compartido, ni indicador de presencia, ni comentarios clavados sobre la vista previa. La unidad de colaboración aquí es una construcción y un enlace, no una sesión en vivo.
¿Cómo trabajan dos personas sobre el mismo proyecto?
Repartiendo papeles en lugar de repartir la pantalla. Una persona tiene la cuenta y lanza los prompts. El resto trabaja desde la dirección publicada y devuelve los cambios en texto, que quien conduce pega como ediciones.
Suena primitivo hasta que notas que el formato de la instrucción y el del comentario son el mismo. "Pon la tabla de precios a tres columnas y sube las preguntas frecuentes encima del pie" es a la vez un comentario y un prompt. No hay traducción entre lo que dice quien revisa y lo que hace el generador.
| Forma de trabajar juntos | Cómo funciona | Qué vigilar |
|---|---|---|
| Quien conduce y quien revisa | Una cuenta construye, el resto abre el enlace y responde con cambios | Agrupa las notas: una edición con seis cambios gana a seis ediciones |
| Cuentas de conectores compartidas | Supabase, Stripe y Vercel son tuyos, así que quien añadas allí ve los datos y los despliegues | El acceso al builder y el acceso a los conectores son cosas separadas |
| Traspaso por repositorio | Exportas a GitHub y usas ramas y revisiones como siempre | Cuando el código avanza en el repositorio, la copia del builder deja de ser la fuente de verdad |
| Proyectos separados, un dueño | Cada persona construye su variante y gana la mejor | Nada se fusiona solo, así que mantén las variantes pequeñas |
La primera fila cubre a la mayoría de los equipos pequeños. La tercera es la que escala, porque en ese punto ya estás usando el modelo de colaboración de GitHub en lugar de pedirle a un generador que invente uno.
¿Quién debería tener la cuenta?
Quien vaya a seguir ahí dentro de seis meses. Los planes se cobran por cuenta: Free incluye 5 créditos una sola vez, Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes. La consecuencia práctica es que los créditos son un bote común y quien tiene el acceso es quien puede gastarlo.
En un equipo fundador, pon la cuenta a nombre de la empresa y con un correo que sobreviva a la marcha de una persona. En una agencia que construye para un cliente, decide pronto si al final el cliente recibe la cuenta o solo el repositorio exportado, porque son traspasos muy distintos.
Los conectores mejoran el cálculo. Supabase guarda la base de datos y el acceso, Stripe guarda el dinero, Vercel puede guardar el alojamiento, y las tres son cuentas que ya controlas tú. Aunque el acceso al builder cambiara de manos mañana, los datos, los cobros y los despliegues no se moverían con él. La puesta en marcha está en la guía de Supabase.
¿Cómo se entrega el proyecto a un desarrollador?
Exportándolo. La exportación a GitHub produce un proyecto estándar en tu propia cuenta, y desde ahí un desarrollador trabaja con herramientas normales: clonar, ramificar, revisar, desplegar. Nada de eso exige que esa persona tenga cuenta en Zugo ni que aprenda a usar el builder.
Es la colaboración más limpia que soporta el producto, porque deja de ser colaboración dentro de un generador y pasa a serlo dentro de un repositorio, donde las herramientas llevan veinte años madurando. Las revisiones, el historial y la vuelta atrás existen ahí y no existen en una ventana de prompts.
Lo que hay que decidir es si el trabajo continúa en los dos sitios. Normalmente no debería. En cuanto alguien empieza a subir cambios al repositorio, trata ese repositorio como la única fuente de verdad, porque lo que se haga luego en el builder vive en otra copia.
Nadie reconcilia esas dos copias por ti, así que la regla merece estar escrita en el encargo y no acordada de palabra. La secuencia completa del traspaso está en si un desarrollador puede retomarlo después.
¿Cuánto cuesta en créditos trabajar en equipo?
Menos de lo que se espera, porque revisar no cuesta nada y solo actuar gasta. Abrir la dirección publicada, leerla, discutirla y escribir notas no consume créditos. Se gasta cuando corre una construcción o una edición.
Una construcción simple cuesta 6 créditos. Una plataforma multipágina cuesta 12 por las tres primeras páginas y 3 por cada página adicional. Una edición cuesta 3 créditos, y el modo Hi-Fi duplica ambas cifras: 12 la construcción y 6 la edición.
Ese modelo premia agrupar los cambios, que además es la disciplina de revisión correcta. Tres personas enviando tres notas sueltas son tres ediciones. Las mismas tres notas reunidas en una sola instrucción son una. Los 200 créditos de Pro dan 66 ediciones si solo los gastas en eso, que son muchas rondas de revisión para un proyecto pequeño.
¿Dónde se rompe esta forma de colaborar?
En cuatro puntos bastante previsibles, y ninguno es un secreto.
Edición simultánea. No existe. Si el proceso de tu equipo depende de que dos personas trabajen en el mismo documento a la vez, esto se sentirá raro desde el primer día.
Fusionar el trabajo de dos personas. Dentro del builder no hay fusión. Dos variantes de un proyecto siguen siendo dos variantes hasta que alguien las rehace a mano o el trabajo se muda a un repositorio.
Permisos por rol dentro del proyecto. El acceso a los conectores se gestiona en Supabase, Stripe, GitHub y Vercel, cada uno con sus reglas. Nadie te entrega un modelo de permisos unificado.
Un producto complejo con varios desarrolladores. Zugo no sustituye a un equipo de desarrollo. Pasado cierto tamaño, la respuesta correcta es que el generador produjo la primera versión deprisa y el equipo la lleva a partir de ahí.
Si vais a ser dos, empezad por lo barato: una cuenta, un enlace publicado y notas agrupadas. Construye la primera versión en Zugo, enséñala y exporta a GitHub en cuanto entre alguien que escriba código. Lo que se lleva la exportación y lo que no, está en si puedes exportar el código.