Constructor de apps con IA y funciones de IA: qué hay
Aquí hay que separar dos cosas distintas. Zugo está construido alrededor de un modelo: describes el proyecto con texto y aparece funcionando. Lo que no existe en la lista de conectores es una integración lista que meta un modelo de lenguaje dentro de tu producto. Esa función se añade exportando el código a GitHub y conectando tu propio proveedor.
Decirlo pronto evita presupuestos mal hechos, así que el resto del artículo desarrolla qué significa cada opción y cuál necesitas de verdad.
¿En qué se diferencia la IA que construye de la IA dentro del producto?
La confusión nace de una misma palabra en dos papeles, y cuesta semanas a quien no la deshace a tiempo.
Primer papel: el modelo como herramienta de construcción. Escribes "web de un estudio de yoga con horario y formulario de reserva" y en alrededor de un minuto tienes páginas funcionando. El modelo actúa en el momento de crear, y en el proyecto terminado ya no está: lo generado es código normal que se abre en el navegador del visitante sin llamar a ninguna red neuronal.
Segundo papel: el modelo como parte del producto. Un asistente en el área de cliente, una descripción automática de producto, el análisis de un documento que sube el usuario. Aquí el modelo se invoca cada vez que alguien usa la función, y cada invocación la paga alguien.
Son cosas distintas técnicamente y en dinero. La primera cabe en los créditos del constructor y es predecible. La segunda implica un gasto continuo que crece con el número de usuarios, y necesita una clave de proveedor, límites y protección de esa clave frente a terceros.
¿Qué integraciones tiene Zugo realmente?
La lista es corta y cerrada, y es más honesto enseñarla entera que describirla con generalidades.
| Integración | Qué aporta al proyecto |
|---|---|
| Supabase | Base de datos, acceso de usuarios y archivos |
| Stripe | Cobros y suscripciones |
| GitHub | Exportación del código fuente a tu repositorio |
| Vercel | Despliegue en tu propia cuenta de hosting |
| Resend | Envío de correos desde el proyecto |
| Dominio propio | Dirección permanente en lugar de tu-slug.zugo.run |
| Google Analytics | Estadísticas de visitas en tu cuenta |
No hay una fila que diga "modelo de lenguaje dentro de tu aplicación". No es un olvido de este artículo ni un hueco temporal: si necesitas un asistente integrado en el producto, planifícalo por la vía del código y no esperando un interruptor en los ajustes.
¿Cómo se añade entonces una función de IA?
El camino que funciona tiene cuatro pasos y se apoya en que el proyecto es tuyo.
Primero, construye y afina en el constructor todo lo que no depende del modelo: páginas, formularios, acceso, base de datos, cobros. Es la parte más voluminosa del trabajo y es justo donde la generación aporta más.
Segundo, exporta el código a GitHub. A partir de ahí tienes un proyecto normal en un repositorio, y lo que sigue no se distingue de cualquier otro desarrollo.
Tercero, un desarrollador añade la llamada al proveedor que elijas. La clave se guarda en el servidor y nunca en el código que llega al navegador: una clave que viaja al navegador es pública por definición, y la encuentran antes de que te des cuenta.
Cuarto, el proyecto se despliega en tu infraestructura, por ejemplo con Vercel. Cómo funciona la salida del código está detallado en constructor de apps con IA y GitHub.
¿Qué se puede resolver sin un modelo en tiempo real?
Antes de contratar a nadie, conviene comprobar si la tarea necesita de verdad un modelo funcionando en cada visita. Bastante a menudo no.
Los textos y descripciones se pueden generar una vez y guardarlos ya escritos en el proyecto. Un catálogo de doscientos productos con descripción no tiene por qué llamar a un modelo cada vez que alguien abre una ficha.
La búsqueda y el filtrado suelen resolverse con una consulta normal a la base de datos. "Enséñame las opciones que encajan" es más veces una condición en Supabase que un modelo de lenguaje, y así funciona más rápido, más barato y de forma repetible.
La personalización de correos se resuelve con plantillas. Resend envía un mensaje sustituyendo el nombre y los datos del pedido, y para eso no hace falta ningún modelo.
La regla es sencilla: el modelo en tiempo de ejecución se justifica cuando la respuesta no se puede calcular de antemano porque depende de una entrada arbitraria del usuario. Todo lo demás sale más barato hecho una sola vez.
¿Qué expectativas sobre "IA dentro" no se cumplen?
Cuatro, y todas se rompen contra la práctica con bastante regularidad.
"El asistente responderá a cualquier duda sobre nuestro producto." Responderá con lo que le des. Sin tu base de conocimiento se inventará características con total seguridad, y eso es peor que no tener asistente: el cliente descontento llega citando tu propia web.
"Será barato, si cada consulta cuesta céntimos." Esos céntimos se multiplican por visitantes y por intentos. Una función que gusta se convierte en una partida visible de gasto justo cuando el proyecto empieza a crecer.
"El modelo sustituirá al buscador del catálogo." Normalmente no. Una consulta a la base de datos da una respuesta exacta y repetible; un modelo da una respuesta verosímil. Para un catálogo esa diferencia es de fondo.
"Nadie va a abusar." Sí lo harán. Una función abierta que llama a un proveedor de pago atrae peticiones automáticas, y sin límites la factura crece sin aportarte nada.
Ninguna de estas objeciones dice que un modelo dentro del producto sea inútil. Dicen que es un producto aparte con su propia economía, no una casilla de configuración.
¿Cuánto cuesta cada parte?
Conviene separar los dos bolsillos, porque se mezclan constantemente.
El trabajo en el constructor se cuenta en créditos. Una construcción cuesta 6, una edición 3, una plataforma multipágina 12 por las tres primeras páginas y 3 por cada 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. Doscientos créditos son unas 33 construcciones rápidas o 16 plataformas completas.
El trabajo del modelo dentro de tu producto se cuenta aparte y se le paga al proveedor que elija tu desarrollador. Ese gasto depende del número de llamadas, así que crece con la audiencia. Métete ese número en la economía del producto desde el principio.
¿Cómo validar la idea antes de escribir código?
Hay una forma barata de saber si la función hace falta antes de pagar por desarrollarla. Se llama hacerlo a mano y parece poco serio hasta que te ahorra un mes.
Construye en el constructor un formulario que reciba la petición del usuario y la guarde en la base de datos. Es una tarea normal para la combinación con Supabase y sale en una sola construcción.
Durante la primera semana responde tú a esas peticiones. Las lees, redactas la respuesta y la envías por correo con Resend. El usuario recibe exactamente el resultado que venía a buscar y no necesita saber que detrás hay una persona.
Al cabo de una semana tendrás tres cosas que no tiene nadie que empezara escribiendo código: las formulaciones reales de las peticiones, el número de personas que usan la función y un conjunto de ejemplos de buena respuesta que después sirve como base para automatizar.
Con cierta frecuencia esa semana termina con la conclusión de que no hace falta automatizar nada, porque llegan diez peticiones y responderlas a mano sale más barato.
¿Dónde está la frontera honesta?
Tres puntos, dichos claros.
No existe un botón de "añadir asistente de IA" dentro del constructor. Si alguien te lo promete, está hablando de otro producto y conviene aclararlo antes de pagar.
Zugo no sustituye a un equipo de desarrollo en un producto complejo, y una integración con un modelo es justo ese caso: claves, límites, manejo de errores y protección contra abusos son ingeniería, no una frase en un prompt.
La lógica de negocio muy específica se afina con ediciones sucesivas y no con un solo prompt. Vale para las funciones normales y más todavía para las que dependen de un proveedor externo.
¿Qué hacer ahora?
Construye en el constructor todo lo que se pueda construir sin modelo en tiempo de ejecución y mira cuánto queda del problema. Suele quedar bastante menos de lo que parecía, y el proyecto sale antes.
Si después de eso sigues necesitando un modelo dentro del producto, exporta el código y conecta el proveedor con un desarrollador. Lo que ya viene resuelto está en Supabase para base de datos y acceso y en puede la IA construir con pagos. Puedes montar la primera versión y medir cuánto trabajo queda en zugo.dev.