Una app no es un workflow invisible: tiene un usuario del otro lado. El diagrama de abajo muestra el ciclo que se repite con cada interacción: el navegador (frontend) hace una solicitud, el servidor (backend) la procesa y devuelve una respuesta, y la pantalla se actualiza.
Diagrama ilustrativo — recreación conceptual del ciclo request/response, no es una captura de pantalla real.
🪟 En segundo plano vs. visible
Hasta aquí, lo que construiste se ejecutaba en segundo plano: workflows y scripts que se ejecutan según un horario o un evento, sin que nadie los supervise. Un app es lo opuesto: es visible — tiene una interfaz con la que interactúan las personas. Esta ruta va desde lo que funciona de forma invisible hasta un producto real en internet, con diseño, autenticación y pago.
💡 El cambio de mentalidad
Una app full-stack es un frontend sobre el backend que ya sabes construir. El enfoque práctico es empezar de forma sencilla —un sitio básico— e iterar agregando features, en vez de planearlo todo de antemano.
- •Fondo: workflow/script sin interacción visible.
- •Visible: una interfaz que otras personas usan.
- •Proyecto-ancla: un AI Lead Qualifier: de la idea a la app en producción.
✓ Piensa como un producto
- ✓Empieza por un sitio web básico y amplíalo con funcionalidades.
- ✓Supone que otras personas van a interactuar con él.
- ✓Trata el frontend como parte del producto, no como adorno.
✗ Trampas
- ✗Intentar planificar el 100% de las funciones antes de publicar.
- ✗Tratar una app como si en el fondo fuera solo un workflow.
- ✗Ignorar que ahora hay un usuario del otro lado.
🎯 Consejo práctico
Empieza poco a poco y publica pronto. Una app sencilla en marcha enseña más que un plan enorme en la cabeza, y cada nueva funcionalidad (diseño, inicio de sesión, pago) se suma como una capa sobre lo que ya funciona.
Workflow sin interfaz.
App con el que se interactúa.
Frontend sobre backend.
Crece por features.
🗺️ Frontend vs. backend
O frontend es todo lo que ve el usuario —botones, imágenes, formularios, textos, fuentes, diseño— y se ejecuta en el navegador. O backend se ejecuta en un servidor: guarda la lógica, hace las solicitudes HTTP, llama a APIs y se comunica con la base de datos. No necesitas dominar cada detalle técnico, pero sí debes interiorizar esta separación: es la base de todo lo demás sobre apps.
🖥️ Frontend (navegador)
- •Botones, formularios, imágenes, textos.
- •Fuentes, colores y diseño: la UX.
- •Lo que el usuario toca y ve.
⚙️ Backend (servidor)
- •La lógica y las reglas de negocio.
- •Solicitudes HTTP y llamadas a la API.
- •Conexión con la base de datos.
🧭 Por qué las apps son distintas de los workflows
Los workflows se ejecutan en segundo plano, sin interacción visible. Las apps requieren una interfaz e interacción en tiempo real: alguien hace clic, espera y ve el resultado. Por eso la UX —navegabilidad, legibilidad de las fuentes, claridad del diseño— pasa a formar parte del producto.
🎯 Consejo práctico
Cuando algo salga mal, pregúntate primero: ¿es frontend (la pantalla no lo muestra) o backend (la lógica no se ejecutó)? Localizar de qué lado está el problema es la mitad del diagnóstico.
Dónde se ejecuta el frontend.
Dónde se ejecuta el backend.
Parte del frontend.
El modelo mental de base.
🔄 Ciclo request/response
Toda app vive de un vaivén continuo entre lo que ve el usuario y lo que ocurre entre bastidores. Ese vaivén es el ciclo request/response: el usuario hace clic, se envía una solicitud al servidor, el servidor la procesa y la respuesta vuelve para actualizar la pantalla.
Las cuatro etapas del ciclo
El usuario hace clic
Una acción en el frontend (enviar un formulario, presionar un botón) activa el ciclo.
La solicitud llega al servidor
El navegador envía los datos al backend, que recibe la solicitud.
El servidor procesa
Guarda datos, llama a una API o ejecuta la lógica: el trabajo entre bastidores.
La respuesta actualiza la UI
El backend devuelve la respuesta y el frontend vuelve a dibujar la pantalla con el resultado.
⏱️ Interacción en tiempo real
Es este ciclo lo que distingue a una app de un workflow en segundo plano: hay alguien esperando del otro lado. Cada interacción es una vuelta completa del ciclo, y la velocidad de esa vuelta forma parte de la experiencia.
🎯 Consejo práctico
Al describir la app a la IA, piensa en términos de ciclo: «cuando el usuario envía el formulario, envía X al backend, procesa Y y muestra Z en pantalla». Eso le da a la IA la forma exacta de la interacción.
Inicio del ciclo.
Frontend → servidor.
Lógica, API, base de datos.
La UI se actualiza.
🎨 Consejos de diseño
Los sitios generados por IA tienden a tener una "aspecto de IA": diseños, colores, gradientes y secciones hero estandarizados. Esto ocurre porque la IA tiende a un "diseño funcional" seguro y predecible, sugerido de la misma forma para todo el mundo. Crear algo original exige orientarla conscientemente, con referencias, vocabulario preciso y feedback específico.
✗ La «cara de IA»
- ✗"Crea una landing page" → resultado genérico.
- ✗Gradientes y hero idénticos a otros mil sitios.
- ✗Comentarios vagos → ciclos infinitos de iteración.
✓ Dirección consciente
- ✓Usar una skill de diseño dedicada.
- ✓Dale referencias concretas (sitios web, capturas de pantalla).
- ✓Decir qué te gustó y qué cambiar, y por qué.
💡 Por qué los outputs de IA se parecen
La IA optimiza para obtener un resultado "seguro": lo que suele funcionar para la mayoría. Sin orientación, entrega el mínimo común denominador. La buena noticia es que responde muy bien a las referencias y al vocabulario: eso es precisamente lo que exploran los dos temas siguientes.
🎯 Consejo práctico
La primera vez que veas la interfaz, di en voz alta qué te gustó y qué no, y por qué. Ese comentario espontáneo es el mejor insumo para la siguiente iteración.
El default de la IA.
Muestra lo que quiere.
Descríbelo con precisión.
Específico, no vago.
🖼️ Skill de diseño y referencias
El atajo de mayor impacto visual es una skill de diseño dedicada: basta con pedirle a la IA que la use al generar la UI y el resultado mejora drásticamente, incluso con un solo prompt. Combina esto con referencias — clonar un sitio que te guste, inspirarte en galerías y usar capturas de pantalla como ejemplo.
Tres formas de mejorar la UI
Pedir la skill de diseño
Al generar la interfaz, pídele a la IA que use la skill de diseño front-end. Es el cambio de mayor impacto con el menor esfuerzo.
Clonar / inspirarse en galerías
Encuentra un sitio que admires y pide que clonen su diseño; busca inspiración en galerías y bibliotecas de componentes.
Usar capturas de pantalla como referencia
Sube una imagen al proyecto y pide «algo parecido a esto» — la IA usa la referencia visual como guía.
🔎 Dónde buscar referencias
Las galerías de diseño y las bibliotecas de componentes son minas de inspiración: diseños probados, paletas y patrones listos para usar. En vez de describirlo todo desde cero, muestra lo que quieres: una referencia vale más que los adjetivos.
🎯 Consejo práctico
Incluso con un solo prompt, activar la skill de diseño hace una diferencia enorme. Si quieres ir más allá, combina la skill con una referencia visual — el resultado queda hecho a tu medida.
Mayor impacto.
Copia un buen sitio.
Inspiración lista.
Referencia por imagen.
🗣️ Lenguaje de prompts de diseño
Describir la interfaz con precisión es lo que transforma una solicitud genérica en un diseño intencional. En vez de "hazlo bonito", nombras diseño, componentes y tono visual — y, al iterar, da comentarios específicos en lugar de decir "está mal".
# Layout Header fixo: logo à esquerda, links de nav à direita. Botão de CTA com glow azul no canto direito. # Hero Texto grande e bold, subtítulo curto, um CTA primário. # Tom visual Escuro, premium, com um acento âmbar e bastante respiro.
✓ Describe con precisión
- ✓Diseño: posición del header, nav, hero y secciones.
- ✓Componentes: tarjetas, botones, formularios, estados.
- ✓Tono visual: paleta, peso de fuente, densidad.
✗ Evita ser vago
- ✗"Hazlo bonito" / "moderno" sin más detalles.
- ✗"Está mal" en vez de decir qué y por qué.
- ✗Cambiar todo de una vez sin aislar lo que no se cambió.
🎯 Consejo práctico
Al iterar, usa la fórmula «me gustó X, pero cambia Y porque Z». Este tipo de comentarios permite actuar; «no me gustó» obliga a la IA a adivinar y genera más vueltas que soluciones.
Dónde va cada cosa.
Cards, botones, formularios.
Paleta y peso.
Me gustó / cambia / por qué.
🚀 Build del AI Lead Qualifier
El proyecto central es una app full-stack de calificación de leads: el backend (workflow) se ejecuta en el Trigger.dev y el frontend en Vercel, conectados para que cualquier persona con la URL pueda usar el workflow. La meta es pasar rápidamente de un prompt simple a una app publicada.
Del prompt a la app publicada
Planificar en Plan Mode
Describe la app (backend en Trigger.dev, frontend en Vercel) y deja que la IA genere el CLAUDE.md y la estructura base antes de programar.
Generar workflow + config de Trigger.dev
La IA crea el workflow de calificación, las instrucciones de deploy y el trigger.config.ts; pega el ID/reference del proyecto.
Deploy del backend (desarrollo + producción)
Implementa la task en los entornos de desarrollo y producción; agrega la clave de la API de IA como variable de entorno en Trigger.dev (idealmente, claves separadas).
Generar y publicar el frontend en Vercel
Genera la UI con la skill de diseño y haz deploy en Vercel: el sitio quedará accesible desde cualquier lugar, con auto-deploy en cada push.
📊 El resultado
Un formulario envía los datos de la empresa → la IA los analiza → muestra un score (p. ej., 68/100, "lead tibio"), un resumen, el desglose del score y los próximos pasos sugeridos; la ejecución correspondiente aparece en los runs de Trigger.dev.
⚠️ Atención
- ✗No pegues secret keys en el chat; pregunta dónde encontrarlas y configúralas tú mismo en las env vars.
- ✗No olvides promover la task al entorno de producción (no solo desarrollo).
Backend / workflow.
Frontend publicado.
CLAUDE.md + base.
Resultado para el usuario.
🔗 Conectar frontend ↔ backend
Con el backend en Trigger.dev y el frontend en Vercel, falta conectarlos. La conexión se realiza mediante variables de entorno: agregas la secret key de Trigger.dev como env var en Vercel, y el frontend empieza a comunicarse con la lógica. Cada push en GitHub activa un deploy automático: el sitio siempre está actualizado.
✓ Cómo conectar
- ✓Obtener la secret key de Trigger.dev (preguntando dónde está).
- ✓Agregarla como env var en Vercel y volver a hacer el deploy.
- ✓Confiar en el auto-deploy con cada push a GitHub.
✗ No lo hagas
- ✗Pegar la secret key en el chat o en el código versionado.
- ✗Olvidar volver a desplegar después de agregar la variable de entorno.
- ✗Confundir el entorno de desarrollo con el de producción.
🎯 Consejo práctico
Piensa en las variables de entorno como el "enchufe" entre el frontend y el backend: el código nunca contiene el secreto, solo lee una variable que vive en la plataforma. Cambiar la clave es cambiar la variable, sin tocar el código.
Autocuración (opcional): ¿cómo se conecta el frontend en Vercel con el backend en Trigger.dev?
📌 Resumen del módulo
Próximo Módulo:
4.2 — Producción real: Auth, seguridad, pagos & integración