El 90% de los Sistemas de Plantillas de Email Se Convierten en Código Legacy en 6 Meses
Vuestra start-up lanza el MVP. El email de bienvenida funciona. También el de reset password. Y el de confirmación de pedido. Todo parece under control.
Seis meses después: 14 tipos de notificación diferentes. Cada una con sus estilos inline inconsistentes. Un archivo HTML de 800 líneas que nadie sabe cómo modificar sin romper algo. Cambios de marca que requieren actualizar 8 templates manualmente.
El problema real no es escribir email templates. Es diseñar un sistema que escale sin convertirse en deuda técnica.
La mayoría de desarrolladores tratan los emails como second-class citizens. Usan strings concatenadas, estilos inline caóticos, y componentes reutilizables que no se reutilizan en absoluto. El resultado: un sistema que funciona, pero que no se mantiene.
Voy a mostraros cómo construir un sistema de templates mantenible con React Email y Resend. Paso a paso. Con código real. Sin atajos.
Por Qué Vuestros Emails Son un Caos de Estilos Inline
Apple Mail, Outlook 365, Gmail en Android. Cada cliente interpreta el HTML del email de forma diferente.
Gmail ignora la mayoría de selectores CSS. Outlook usa motores de renderizado que existían en 2007. Apple Mail soporta cosas que otros browsers llevan años implementando.
La mayoría de developers responden a esta realidad con la estrategia del mínimo común denominador: estilos inline en cada elemento, tablas para el layout, nada de CSS moderno. Funciona, pero el código resultante es inmantenible.
Ejemplo del caos que veis típicamente:
Repetís este patrón 14 veces. Cada template con sus propios valores hardcodeados. Colores que no coinciden. Fonts que cambian entre emails. Cuando el brand team pide actualizar el color primario, tenéis un problema.
El Framework de Componentes Jerárquicos para Email Templates
La solución no es escribir mejor HTML inline. Es crear una arquitectura de componentes que enforce consistencia a nivel de sistema.
Os presento el Sistema de Capas para Email Templates. Tres niveles que se construyen uno sobre otro:
Capa 1: Tokens de Diseño Centralizados
Primero, definís los valores que se repiten: colores, spacing, tipografía. No en cada componente. En un lugar único.
Estos tokens son la única fuente de verdad. Cambiáis el color primario aquí, se actualiza en todos los emails.
Capa 2: Componentes Base Email-Ready
Segundo, creáis componentes que ya incorporan las limitaciones de email clients. No escribís <div>, escribís componentes que saben renderizarse correctamente en Outlook y Gmail.
Estos componentes ya saben cómo comportarse en email clients. El Card usa <table> internamente porque es lo que funciona en Outlook. El Button usa <a> con estilos inline porque los <button> no se estilizan consistentemente.
Capa 3: Templates Específicos por Tipo de Notificación
Tercero, construís los templates concretos. Éstos compilan los tokens y componentes base en emails reales.
Este template sabe cómo renderizarse correctamente. Cada componente heredado de las capas anteriores enforce el diseño system. Cuando vuestro brand team cambie el color primario, solo tocáis design-tokens.ts.
Envío Real con Resend: El Paso que Falta
Construir el template es la mitad del trabajo. La otra mitad es enviarlo correctamente.
Configuráis el cliente de Resend:
Definís una función helper que simplifica el envío:
Uso real en una API route:
Este patrón escala. Cada tipo de notificación tiene su template. Cada template usa los tokens centralizados. Cambiáis el brand una vez, se actualiza en todos los emails.
La Partición de Notificaciones: El Error que Crea 200 Líneas de Código Muerto
La mayoría de sistemas de email tienen un solo archivo sendEmail.ts con 50 funciones diferentes. Una para cada notificación. Mezcladas. Sin organización.
Esto es un antipatrón.
A medida que vuestra app crece, termináis con sendWelcomeEmail, sendPasswordResetEmail, sendOrderConfirmationEmail, sendInvoiceEmail, sendTrialEndingEmail, sendTrialEndedEmail. Todas en el mismo archivo. Dependencias compartidas que no tienen sentido. Lógica de negocio mezclada con lógica de email.
La solución: particionar por dominio de negocio, no por tipo de email.
Cada dominio tiene su carpeta. Cada template está donde esperáis encontrarlo. Cuando añadís una nueva notificación, sabéis exactamente dónde va.
Preview y Testing: El Workflow que Previene Emails Rotos en Producción
No mandáis código a producción sin tests. ¿Por qué mandáis emails sin verificarlos antes?
React Email incluye un servidor de preview que funciona durante desarrollo:
Este comando levanta una interfaz web donde veis cada template renderizado. Cambiáis un color en design-tokens.ts, recargáis, y verificáis que todo sigue funcionando.
Para testing automatizado, usáis @react-email/testing:
Este test verifica que el contenido es correcto y los links funcionan. No es un test de renderizado visual (eso lo hacéis en el servidor de preview), pero captura regresiones de contenido.
Resumen: El Sistema Completo
Un sistema de email templates mantenible tiene tres ingredientes:
- Tokens centralizados: Un archivo con colores, spacing, tipografía. Cambiáis una vez, se actualiza en todos los emails.
- Componentes base email-ready: Abstracciones que saben renderizarse en clientesproblemáticos como Outlook.
- Templates por dominio: Organización clara que escala cuando añadís nuevas notificaciones.
La próxima vez que alguien os pida cambiar el color primario de todos los emails, no vais a temblar. Abrís design-tokens.ts, cambiáis un valor, y el deploy se encarga del resto.
El mejor sistema de email templates es el que no notáis. El que os permite añadir una nueva notificación en 15 minutos sin pensar en estilos inline ni compatibilidad con clientes.
Empezad con los tokens. Construid componentes base. Después los templates. En ese orden. Sin atajos.
Vuestra bandeja de entrada del brand team os lo agradecerá.
Artículos relacionados
- Resend en Producción: Patrones Avanzados que el Tutorial Básico No Te Enseña
- Next.js en Producción: La Arquitectura que Separa los Proyectos que Escalan de los que Explotan
- Resend en Producción: Monitorización, Analíticas y Gestión de Bounces que Nadie Te Explica
- Schema Design Patterns en Sanity.io: Cómo Construir Schemas que Sobreviven a Tus Migraciones
- React Email Components: El Patrón que Funciona en el 100% de Clientes de Correo
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
