Constructor de apps con IA y Resend: correos del proyecto

Sí. Resend es la integración de correo de Zugo y se ocupa de los mensajes que envía tu proyecto: confirmación de un formulario, aviso de un pedido, recuperación de acceso. La cuenta de Resend es tuya y se paga aparte, igual que Supabase o Stripe. Conectarla no consume créditos; los créditos se gastan en construir y editar.

Casi todo el mundo descubre que necesita correo el día del lanzamiento, cuando alguien rellena un formulario y no recibe nada. Vale la pena decidirlo antes.

¿Qué correos necesita de verdad un proyecto?

Menos de los que parece al principio y más de los que suele incluir la primera versión. Esta tabla ordena los habituales por cuánto duele no tenerlos.

Las cinco primeras filas son correo transaccional: se disparan por una acción concreta de una persona concreta y se esperan en segundos. La última es marketing y funciona con otras reglas, otras herramientas y otro consentimiento.

Si tu proyecto tiene formulario, empieza por las dos primeras filas. Cubren la mayoría del daño con el menor trabajo.

¿Cómo describir los correos en el prompt?

Con el mismo nivel de concreción que usarías para una página. El modelo traduce bien lo específico y adivina mal lo que no le dices.

Una descripción floja: "que mande un correo cuando alguien reserve". No dice a quién, ni con qué datos, ni qué debe hacer el destinatario después.

Una descripción sólida: "Cuando alguien envía el formulario de reserva, manda dos correos. Al cliente: confirmación con fecha, hora, servicio, dirección del local y un enlace para cancelar. A la dirección del negocio: aviso con el nombre, el teléfono, el servicio y la hora, con asunto que incluya la fecha para poder ordenarlos en la bandeja."

Ahí hay dos destinatarios, los campos exactos y una pista sobre el asunto. El resultado es previsible, y lo que falte se corrige con una edición de 3 créditos en lugar de con una discusión.

Un detalle que casi nadie pide y siempre agradece: que el correo al negocio incluya en el asunto el dato por el que vas a buscar después. Cuando lleguen doscientos, esa decisión vale más que el diseño del mensaje.

¿Qué diferencia hay entre correo transaccional y boletín?

Es una diferencia legal y práctica, no un matiz de vocabulario, y confundirlas es la forma más rápida de acabar en la carpeta de spam.

El correo transaccional responde a algo que la persona acaba de hacer. Compró, reservó, pidió recuperar el acceso. No necesita suscripción porque no es promoción: es la consecuencia directa de su acción.

El boletín se envía porque tú decides enviarlo, y ahí sí hace falta consentimiento explícito, forma sencilla de darse de baja y registro de quién aceptó y cuándo. Las obligaciones concretas dependen de tu jurisdicción y de a quién escribas.

La mezcla peligrosa es meter una oferta dentro de un correo transaccional. Técnicamente sale, y funciona hasta que suficientes personas lo marcan como no deseado y arrastran también las confirmaciones legítimas. Mantén los dos flujos separados.

¿Por qué los correos acaban en spam?

Rara vez por el contenido y casi siempre por la configuración del dominio, que es un tema aparte del proyecto.

Un correo enviado desde tu dominio necesita que el dominio autorice al servicio a enviar en su nombre. Eso se hace con registros DNS de autenticación, y son los mismos que ya tocas si conectaste un dominio propio. Sin ellos, muchos proveedores tratan el mensaje con desconfianza aunque el contenido sea impecable.

Otros dos factores pesan. Enviar desde una dirección de dominio gratuito en lugar del tuyo debilita la confianza. Y una dirección nueva sin histórico empieza sin reputación, así que los primeros envíos masivos llaman más la atención que los de un dominio que lleva meses enviando poco y bien.

La consecuencia práctica: conecta el dominio propio y configura la autenticación antes de anunciar el proyecto, no después de la primera queja de que "no llega nada".

¿Qué revisar antes de lanzar?

Cinco comprobaciones, todas de diez minutos, todas necesarias porque el correo falla en silencio.

Envía una prueba a tres proveedores distintos. Un mensaje que entra perfecto en un buzón puede caer en promociones en otro, y con una sola cuenta de prueba nunca lo sabrás.

Ábrelo en el móvil. La mayoría del correo se lee ahí, y una tabla ancha o una imagen enorme se ve mucho peor en pantalla estrecha que en el navegador donde lo revisaste.

Comprueba que el nombre y la dirección del remitente son los que quieres. "notificaciones@tu-dominio" transmite algo distinto de una dirección genérica del servicio, y cambiarlo después de tener miles de mensajes enviados es más incómodo.

Haz clic en todos los enlaces del correo desde el correo, no desde el editor. Un enlace mal formado dentro de una plantilla es un fallo clásico y no aparece en ninguna revisión visual.

Prueba el caso de error. ¿Qué ve la persona si el envío falla? Una página que dice "listo" mientras el correo no salió es peor que un mensaje de error honesto.

¿Cuánto cuesta esto?

Conectar Resend no gasta créditos, y Resend se paga a Resend bajo sus propias condiciones. Lo que se paga en créditos es la generación.

Una construcción cuesta 6 créditos y una edición 3. Una plataforma multipágina cuesta 12 por las tres primeras páginas y 3 por cada página adicional. En modo Hi-Fi todo vale el doble: 12 la construcción y 6 la edición. El plan gratuito incluye 5 créditos, Pro cuesta $25 al mes con 200 créditos y Business cuesta $99 al mes.

Un proyecto que envía correos casi siempre es una plataforma con base de datos y acceso, no una página suelta. Presupuesta con ese número: 200 créditos son 16 plataformas completas, y afinar los textos de los correos suele llevarse dos o tres ediciones adicionales por proyecto.

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

Tres, sin adornos.

La entregabilidad no depende del constructor. Zugo escribe la integración; que el mensaje llegue a la bandeja principal depende de tu dominio, de tu reputación y de las reglas de cada proveedor de correo.

La comprobación en entorno de pruebas verifica que el proyecto arranca antes de entregártelo, y una construcción que no abre no se entrega. No comprueba que tu correo llegue, ni que el texto diga lo correcto.

Zugo no sustituye a un equipo de desarrollo en un producto complejo. Los flujos de correo con muchas condiciones, reintentos y estados se afinan con ediciones sucesivas, y llegado cierto punto sale más barato exportar el código y continuar a mano.

¿Qué hacer ahora?

Escribe la lista de correos de tu proyecto antes de la primera construcción: destinatario, disparador y campos. Son cinco líneas y ahorran varias ediciones.

Después construye, conecta el dominio, configura la autenticación y prueba en tres buzones distintos antes de invitar a nadie. Para el contexto alrededor, Supabase para base de datos y acceso cubre la parte de usuarios, Stripe para cobros la parte de dinero y dominio propio la dirección desde la que enviarás. Puedes montar la primera versión en zugo.dev y probar el envío el mismo día.