¿Puede un desarrollador retomar el proyecto después?
Sí, y es la salida prevista. Exportas el código a un repositorio de GitHub en tu cuenta, y a partir de ahí un desarrollador clona, ramifica, revisa y despliega con herramientas normales, sin necesitar cuenta en Zugo ni aprender a usar el generador. El proyecto es tuyo, así que la puerta está siempre abierta.
Lo que decide si el traspaso sale bien no es técnico. Es cuándo lo haces y qué entregas junto al código, porque un repositorio sin contexto obliga a esa persona a deducir tus reglas de negocio leyendo pantallas.
¿Qué recibe exactamente el desarrollador?
Un proyecto estándar en un repositorio bajo tu control: archivos fuente, configuración y manifiesto de dependencias, suficiente para clonarlo y arrancarlo. Nada va minificado ni ofuscado, porque es el mismo código con el que funcionaba la construcción.
Lo que no viaja con el código son las cosas que nunca fueron código, y conviene decirlo antes de la primera reunión. Las tablas y las filas siguen en tu proyecto de Supabase. Los pagos y los clientes siguen en tu cuenta de Stripe. La dirección publicada sigue apuntando al alojamiento de Zugo hasta que decidas otra cosa.
Ese reparto es una ventaja en el traspaso, no una carencia. Significa que puedes dar acceso al código sin dar acceso al dinero, o al revés, y que cambiar de persona no mueve tus datos de sitio. Lo que se lleva y lo que no está detallado en si puedes exportar el código.
¿Cuándo conviene traer a un desarrollador?
Cuando el coste de seguir con ediciones supera al de un rato de trabajo humano, y eso ocurre antes de lo que la gente cree en unos casos y mucho después en otros.
| Señal | Qué significa | Qué hacer |
|---|---|---|
| La misma edición vuelve tres veces | La instrucción no cabe en una frase | Traspaso o pareja de ediciones más específicas |
| El producto ya cobra dinero real | El fallo tiene coste, no solo molestia | Que alguien revise acceso y cobros |
| Hay reglas con muchos casos límite | Aprobaciones, permisos por campo, descuentos condicionados | Trabajo humano sobre el repositorio |
| Se acerca una integración que no está en la lista | Necesitas un servicio externo concreto | Desarrollo sobre el código exportado |
| Solo quieres otro color y otro texto | Cambio cosmético | Una edición de 3 créditos, no un desarrollador |
La última fila existe porque el error más caro es el contrario al que se teme. Contratar a alguien para cambiar textos y colores gasta dinero en algo que cuesta 3 créditos, y esa persona además tendrá que montarse el entorno primero.
La regla razonable es distinguir cambios de superficie de cambios de reglas. La superficie es barata y rápida en el generador. Las reglas con muchas excepciones se afinan mejor en código, y ahí es donde alguien con oficio devuelve su coste enseguida.
¿Qué hay que entregar además del código?
Cuatro cosas, y ninguna es técnica. La primera es el acceso a los conectores que use el proyecto, con permisos separados: base de datos, pagos, correo y despliegue no tienen por qué ir en el mismo lote.
La segunda son las reglas de negocio escritas en lenguaje normal. Quién ve qué, qué pasa al cancelar, qué ocurre cuando dos personas hacen lo mismo a la vez. Ese documento de media página ahorra días de arqueología y evita que se reimplemente una regla al revés.
La tercera es la lista de lo que ya sabes que está a medias. Toda construcción tiene bordes sin pulir, y decirlos por adelantado es más barato que dejar que se descubran facturando por horas.
La cuarta es la decisión sobre dónde vive la verdad. En cuanto alguien sube cambios al repositorio, ese repositorio es la fuente única y el builder deja de serlo, porque lo que edites después queda en otra copia y nadie las reconcilia por ti.
Vale la pena escribir esa cuarta decisión en el propio encargo, no acordarla de palabra. "A partir del día que empieces, los cambios van al repositorio y yo no toco el generador" es una frase corta que evita el escenario más frecuente y más caro: dos versiones del mismo producto avanzando en paralelo y nadie sabiendo cuál se está publicando.
¿Es más barato empezar con IA y contratar después?
Casi siempre, y el motivo no es el precio de la herramienta sino el del malentendido. Un desarrollador que recibe algo que funciona presupuesta sobre algo concreto; uno que recibe una descripción presupuesta sobre su interpretación de esa descripción.
Las cuentas ayudan a decidir. 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. Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes.
Y hay que ser justos con la alternativa: un buen profesional aporta cosas que un generador no aporta, y no solo código. Aporta criterio sobre qué no construir, responsabilidad cuando algo falla en producción y experiencia con problemas que aún no sabes que vas a tener. La comparación completa está en builder con IA frente a freelance.
El orden que suele salir mejor es prototipo primero, contrato después. Con una versión publicada en la mano, la conversación deja de ser "qué quiero" y pasa a ser "qué falta", que es una conversación mucho más barata para los dos lados.
¿Qué debe revisar esa persona el primer día?
Lo mismo que revisarías tú si supieras: las reglas de acceso. Que la base de datos se niegue a devolver las filas de otra cuenta, y no solo que la interfaz las oculte, es la comprobación que separa un producto presentable de uno con un problema esperando.
Después, el circuito del dinero si lo hay. Que el precio mostrado sea el cobrado, que el pedido quede registrado, que el correo de confirmación se envíe y diga lo correcto. Son cuatro momentos y se prueban en veinte minutos.
Y por último, lo aburrido: que no haya claves ni contraseñas dentro del repositorio, que exista una copia de seguridad de los datos y que quede claro cómo se despliega una versión nueva.
Recuerda además qué cubre la comprobación previa. Cada construcción se arranca en un entorno aislado antes de entregarse y una que no abre se reporta como fallo, lo que reduce el riesgo de una página en blanco sin decir nada sobre la calidad de tus reglas de negocio.
¿Dónde está el límite honesto?
En que un generador y un equipo resuelven problemas distintos. Zugo no sustituye a un equipo de desarrollo en un producto complejo, y la lógica muy específica se construye por capas con ediciones en lugar de salir de un prompt gigante.
Lo que sí hace, y es mucho, es quitar de en medio la parte que se repite en todos los proyectos: la estructura, las pantallas, los formularios, la conexión con la base de datos y el circuito de pago. Empezar con eso hecho es empezar con la mitad barata resuelta.
También conviene ser honesto con el otro sentido del traspaso: hay proyectos que nunca necesitarán uno. Una web de servicios, un portafolio o una herramienta interna pequeña pueden vivir años a base de ediciones ocasionales, y llamar a un desarrollador ahí sería pagar por capacidad que no vas a usar.
Así que la respuesta corta es que no estás eligiendo entre IA y desarrollador, estás eligiendo el orden. Construye la primera versión en Zugo, publícala, aprende qué falta con usuarios reales delante y entrega un repositorio con contexto cuando toque. Si además dudas entre profesional independiente y estudio, está en builder con IA frente a agencia.