Resend no es un Proveedor de Email. Es el Caballo de Troya para Escapar del Vendor Lock-In

# Resend no es un Proveedor de Email. Es el Caballo de Troya para Escapar del Vendor Lock-In

Tu Plantilla de Email Está Secuestrada y No lo Sabes

Abre tu dashboard de SendGrid. Mira cualquiera de tus templates activos.

*No puedes mover esa plantilla a Mailgun sin reescribirla desde cero. *

No es culpa tuya. Es el modelo de negocio. SendGrid, Mailgun, SES — todos os atan a su formato de plantillas porque la retención es más rentable que la calidad. Los proveedores legacy no compiten en calidad de servicio: compiten en coste de salida. Saben que una vez que tenéis 50 plantillas en su ecosistema, cambiaros es tan doloroso que preferís aguantar una API mala antes que migrar.

*Resend no es un proveedor de email. Es el caballo de Troya que rompe ese secuestro. *

Zeno Rocha fundó Resend en 2023 con una premisa que sonaba ingenua: la experiencia de desarrollador debería pesar más que las features empresariales. Dos años después, equipos de Vercel, Apple y Supabase han migrado su email transaccional. No por precio. Por algo más profundo.

Este artículo no es otro tutorial de "cómo enviar un email con Resend". Es una advertencia: si seguís atados a plantillas HTML en strings, vais a pagar el peaje del vendor lock-in en el peor momento posible.

Pensadlo en términos de paralelismo histórico. Durante años, las empresas construyeron su infraestructura de bases de datos atadas a Oracle. Cuando llegaron PostgreSQL y MongoDB, el coste de migrar era tan alto que muchas prefirieron seguir pagando licencias astronómicas antes que reescribir sus queries y schemas. El email transaccional está siguiendo exactamente el mismo patrón, solo que nadie lo llama por su nombre. El vendor lock-in en email es el nuevo Oracle lock-in, y está ocurriendo delante de nuestros ojos mientras aceptamos como normal tener plantillas secuestradas en dashboards ajenos.

---

El Problema que Nadie Quiere Reconocer

El mercado del email transaccional está fragmentado por una razón que poco tiene que ver con tecnología:

*El coste real de cambiar de proveedor no es la migración técnica. Es la migración de plantillas. *

SendGrid fue fundado en 2009. Su API v3 arrastra deuda técnica de quince años. Las plantillas usan Handlebars, un motor de templates que requiere lógica de presentación mezclada con HTML. Mailgun usa MJML personalizado. SES os obliga a subir HTML estático.

Lo que ocurre en la práctica es todavía más sutil. Cuando un equipo elige SendGrid, no solo está eligiendo un proveedor de envío: está eligiendo un ecosistema de plantillas. Y ese ecosistema tiene sus propias reglas, sus propias limitaciones de sintaxis, su propio sistema de versionado, y su propio editor visual que genera código difícil de mantener fuera de la plataforma. Es como si cada vez que cambias de lenguaje de programación tuvieras que reescribir toda tu lógica de presentación desde cero. Eso no es una migración: es una reescritura forzada.

❌ El enfoque legacy (la mayoría hace esto):

Creas una plantilla en el dashboard del proveedor
La editas con el editor visual o con HTML crudo
Si cambias de proveedor, pierdes todas las plantillas
Reescribes una por una en el nuevo formato
El equipo de ingeniería pierde semanas

✅ El enfoque Resend + React Email:

Escribes la plantilla como un componente React estándar
Ese componente no depende de ningún proveedor
Renderizas el componente a HTML estático en build time
Envías el HTML por cualquier API (Resend, SendGrid, SES, la que sea)
Cambiar de proveedor es cambiar tres líneas de configuración

*La diferencia no es estética. Es arquitectónica. *

Cuando tu plantilla es un componente React, dejas de depender del ecosistema del proveedor. La lógica de presentación vive en tu codebase, no en un dashboard web al que pierdes acceso si no pagas la factura. Es la misma filosofía que llevó a la industria a migrar de bases de datos propietarias a PostgreSQL: la libertad de mover tus datos donde quieras.

Y aquí hay un punto crítico que la mayoría pasa por alto: cuando tu plantilla vive en tu codebase, también heredas todo el ecosistema de herramientas de desarrollo que ya usas. Control de versiones con Git, code reviews con pull requests, tests unitarios y de integración, despliegue continuo con CI/CD. Ninguna de esas prácticas es posible cuando tu plantilla está en un dashboard web. El editor visual de SendGrid no tiene Git integration. Su sistema de versionado es básico. No puedes hacer un code review de un cambio en una plantilla de Mailgun porque no hay un diff que mostrar. Estás operando con herramientas de 2009 para un problema de 2026.

---

La Evidencia: Por Qué Esto No es Hype

Los datos no mienten. El equipo de Resend ha priorizado la portabilidad desde el día uno.

SDKs oficiales para más de 10 lenguajes y frameworks: Node.js, Python, Go, Ruby, PHP, Elixir, Java, .NET, React, Next.js. Eso es más cobertura que SendGrid, Mailgun y SES combinados en SDKs mantenidos activamente.

Integración nativa con React Email: Las plantillas se escriben en JSX. No Handlebars. No MJML propietario. No HTML en strings malditos. Componentes React que renderizan a HTML estático.

Pero el dato que realmente importa no es técnico. Es de mercado: empresas que podrían permitirse cualquier proveedor — Vercel, Apple, Supabase — han elegido Resend para email transaccional en producción. No por moda. Porque cuando tu infraestructura escala, la portabilidad de las plantillas deja de ser una "nice-to-have" y se convierte en un requisito de supervivencia.

Pensad en lo que significa que Apple — una compañía que construye sus propios chips, sus propios servidores, sus propias herramientas internas — haya elegido Resend para su email transaccional. Apple no necesita que un proveedor le dé "enterprise features". Apple puede construir cualquier cosa que necesite. Lo que Apple no puede hacer es perder tiempo migrando plantillas cada vez que decide cambiar de proveedor. El coste de oportunidad de tener un equipo de ingeniería reescribiendo plantillas durante semanas es más alto que cualquier ahorro en el coste por email. Eso es lo que Resend entiende y lo que SendGrid nunca ha entendido.

Y hay un contexto más amplio que refuerza esta tesis. Google Cloud ha documentado internamente que el mayor bloqueador de adopción de nuevas herramientas no es la calidad del producto — es la fricción en el workflow existente. Sarah Kennedy Ellis, VP of Growth en Google Cloud, lo dijo claro en SaaStr AI 2026: "*The greatest friction in a workflow is the biggest inhibitor to adoption. *" Resend + React Email elimina exactamente esa fricción: el workflow de crear, mantener y migrar plantillas.

Este principio no es exclusivo del email. Lo estamos viendo en todos los ámbitos del desarrollo de software. Las herramientas que triunfan no son necesariamente las mejores técnicamente hablando: son las que reducen la fricción en el workflow del desarrollador. Git triunfó sobre SVN no porque fuera más potente, sino porque el workflow de branching y merging era más natural. VS Code triunfó sobre Eclipse no porque tuviera más features, sino porque eliminaba la fricción de la configuración inicial. Resend está siguiendo exactamente ese mismo patrón: no compite en features, compite en eliminar la fricción del workflow de email.

---

El Marco de 5 Pasos: Cómo Migrar de SendGrid/SES a Resend (y Poder Irte Cuando Quieras)

Llamémoslo El Principio de Portabilidad Reactiva. No migráis a Resend porque sea mejor. Migráis porque desacopla vuestras plantillas del proveedor, y eso os da libertad para cambiar cuando queráis.

Paso 1: Audita tu tiempo real por email enviado

Mide cuánto tarda tu equipo desde que escribe una plantilla hasta que la ve en producción.

Si supera 30 minutos, tenéis un problema de proceso, no de herramienta. SendGrid, SES u otro proveedor no es la causa — es el síntoma. La causa es que vuestras plantillas están secuestradas en un dashboard ajeno.

Pero la auditoría no debería limitarse al tiempo. Preguntaos también: ¿cuántas personas intervienen en el proceso? ¿Cuántos aprobadores? ¿Cuántos entornos (desarrollo, staging, producción) necesitan tocar? En una empresa mediana, un cambio de plantilla puede requerir: un diseñador que la maqueta en Figma, un desarrollador que la implementa en SendGrid, un QA que la prueba en staging, un manager que aprueba en producción, y un DevOps que ejecuta el deploy. Eso son cinco personas para lo que debería ser un cambio de un archivo en tu codebase.

Si además trabajáis con SES, la cosa se complica todavía más. No solo tenéis que subir el HTML estático, sino que además necesitáis gestionar la configuración de SNS para los bounces, una Lambda para procesar las notificaciones, CloudWatch para los logs, y un IAM role con los permisos exactos. El tiempo real de una plantilla en SES no es lo que tardáis en escribir el HTML: es lo que tardáis en configurar toda la infraestructura que rodea al envío. Y esa infraestructura no es portable.

Paso 2: Extrae y convierte tus plantillas a React Email

*Fijaos en lo que no hay. No hay referencias a Resend. No hay configuración de un proveedor. Es un componente React estándar que podéis renderizar con cualquier* backend de email.

Este paso parece trivial, pero es el más importante de todos. Porque cuando extraéis la plantilla del dashboard del proveedor y la convertís en un componente React, estáis haciendo algo que va más allá de la tecnología: estáis cambiando la propiedad intelectual de vuestras plantillas. Hasta ahora, vuestras plantillas eran propiedad del proveedor en la práctica — no legalmente, pero sí funcionalmente, porque sin su dashboard no podíais editarlas ni moverlas. Al convertirlas en componentes React, las devolvéis a vuestro control. Vuestro equipo de ingeniería puede versionarlas, revisarlas, testearlas y desplegarlas como cualquier otra pieza de código.

Además, la conversión a React Email abre puertas que los templates tradicionales no pueden ofrecer. ¿Necesitáis un footer que cambie dinámicamente según el país del usuario? En Handlebars tendríais que escribir lógica condicional dentro del HTML, mezclando presentación con lógica de negocio. En React Email, simplemente creáis un componente Footer que recibe el país como prop y renderiza lo que corresponda. La separación de concerns es limpia, testable y mantenible.

Paso 3: Configura autenticación DNS desde el dashboard de Resend

DKIM, SPF, DMARC. En SES necesitáis Route53, IAM, verificación de dominio y una Lambda para procesar los rebotes.

En Resend: dos clics en el dashboard. Añadís los registros TXT que os da, y listo.

No necesitáis tocar CloudFormation. No necesitáis IAM. DNS y ya.

Ahora bien, hay un matiz importante aquí. La configuración DNS en Resend es más simple porque Resend gestiona la infraestructura de reputación de dominios por vosotros. Eso significa que no tenéis control granular sobre las IPs desde las que se envían vuestros emails. Para el 95% de los equipos, esto no es un problema. Pero si sois una empresa que envía cientos de miles de emails al día y necesitáis IPs dedicadas con reputación separada para distintos tipos de email (transaccional vs marketing), este es un punto que debéis considerar.

Sin embargo, incluso en ese caso, la compensación merece la pena. La configuración manual de DKIM, SPF y DMARC en AWS es propensa a errores. Un registro mal configurado puede tirar vuestra reputación de dominio durante semanas. Con Resend, la gestión de la autenticación es responsabilidad de ellos, y si algo falla, el equipo de soporte de Resend lo detecta antes de que afecte a vuestra deliverability.

Paso 4: Implementa un endpoint de prueba en Next.js App Router

*Diez minutos. * Desde clonar el repo hasta tener el primer email en producción.

Compáralo con SES: necesitáis configurar SNS para los bounces, una Lambda para procesar las notificaciones, CloudWatch para los logs, y un IAM role con los permisos exactos. Eso no son 10 minutos. Son 2-3 horas de un senior engineer.

❌ SES (coste real): ~2-3 horas de configuración + mantenimiento continuo

✅ Resend (coste real): ~10 minutos y olvidaros

La diferencia no está solo en el tiempo inicial. Está en el mantenimiento continuo. Con SES, cada vez que alguien del equipo hace un cambio en la configuración de IAM, puede romper la entrega de emails. Cada vez que AWS actualiza su política de SNS, tenéis que revisar si vuestra configuración sigue siendo válida. Es un coste operativo que se acumula mes tras mes, y que la mayoría de los equipos ni siquiera contabilizan porque lo dan por sentado. Es como el "tax" del vendor lock-in: no lo ves en la factura mensual, pero lo pagas en horas de ingeniería.

Paso 5: Periodo de evaluación paralelo con el 10% del tráfico real

No migréis el 100% del tráfico el primer día. Enviad el 10% por Resend durante dos semanas. Comparad:

Tasa de apertura: ¿Son comparables o peores?
Tasa de bounce: ¿Hay problemas de reputación del dominio?
Spam reports: ¿Los filtros de Gmail/Outlook penalizan a Resend?

Si las métricas son iguales o mejores, migráis el resto. Si no, tenéis datos para decidir.

Este paso es clave porque elimina el riesgo de la migración. No estáis apostando el negocio a un cambio de proveedor. Estáis ejecutando un experimento controlado con datos reales de vuestro dominio y vuestros usuarios. Si las métricas empeoran, tenéis la respuesta antes de que el problema afecte a la mayoría de vuestros clientes. Y si mejoran — que es lo más probable cuando trabajáis con una infraestructura de entrega optimizada como la de Resend — tenéis la justificación numérica para completar la migración sin discusiones internas.

Además, este periodo de evaluación paralelo os sirve para validar algo que ningún benchmark puede medir: la latencia de entrega en vuestro caso de uso concreto. Los proveedores de email tienen distintos patrones de entrega dependiendo del volumen, la hora del día, y la reputación del dominio. Lo que funciona para una empresa SaaS en San Francisco puede no funcionar para un ecommerce en Barcelona. La única forma de saberlo es con tráfico real.

---

Y la Objeción Más Común: "Resend es para Startups, No para Producción Serious"

La he oído decenas de veces. Y siempre viene de alguien que confunde antigüedad con madurez.

Resend procesa miles de millones de emails al mes. Empresas como Vercel, Apple y Supabase lo usan en producción. La madurez no es cuántos años lleva un producto — es cuánto ha sido probado bajo carga real.

¿El riesgo real de Resend? Si necesitáis enviar 200k emails/hora con control granular de IPs de reputación dedicadas, Resend puede quedaros corto. Son sinceros con sus límites.

Pero para el 95% de los equipos — startups, scale-ups, productos SaaS — la simplicidad pesa más que las features que nunca usaréis.

Hay una dinámica psicológica interesante aquí. Cuando un equipo lleva años usando SES o SendGrid, el hecho de que la configuración sea compleja se convierte en una señal de "profesionalismo". Si es difícil, debe ser serio. Si es simple, debe ser para startups. Es el mismo sesgo que lleva a algunos equipos a pensar que una base de datos que requiere un DBA a tiempo completo es más "seria" que una base de datos que se configura con dos comandos. La realidad es que la complejidad innecesaria no es una señal de madurez: es deuda técnica disfrazada de sofisticación.

---

Lo Que Nadie os Cuenta Sobre el Vendor Lock-In en Email

Los proveedores legacy no compiten en calidad de servicio. Compiten en coste de salida.

SendGrid y SES saben que una vez que tenéis 50 plantillas en su ecosistema, cambiaros es tan doloroso que preferís aguantar una API mala antes que migrar.

*Resend + React Email rompe ese ciclo. *

Vuestras plantillas son vuestras. Renderizables a HTML estático. Enviables por cualquier API. Si mañana Resend desaparece, cambiáis el backend y vuestros emails siguen funcionando. Eso no es posible con SendGrid, Mailgun, o SES.

Pensad en ello como una póliza de seguros para vuestra infraestructura de email. El coste de implementar React Email hoy es relativamente bajo — unas horas de un desarrollador para convertir las plantillas principales. Pero el beneficio futuro, si alguna vez necesitáis cambiar de proveedor, es inmenso. No es que planeéis que Resend desaparezca. Es que no necesitáis planearlo. La portabilidad os da la tranquilidad de saber que, pase lo que pase, vuestras plantillas no son rehenes.

Y esto es especialmente relevante en el contexto actual del mercado de herramientas de desarrollo. Estamos viendo una consolidación acelerada: empresas que compran a sus competidores, productos que se rediseñan o se abandonan, APIs que cambian sin previo aviso. El proveedor de email que elegís hoy puede no ser el mismo dentro de dos años. Si vuestras plantillas dependen de su ecosistema, estaréis atrapados en una relación que quizá ya no queráis mantener. Con React Email, esa preocupación desaparece.

---

Resumen y Una Declaración

| Problema | Solución Legacy | Solución Resend + React Email |

|----------|----------------|-------------------------------|

| Plantillas secuestradas | En dashboard del proveedor | En tu codebase como componentes React |

| Migración de proveedor | Reescribir todas las plantillas | Cambiar 3 líneas de configuración |

| Configuración inicial | Horas (SES: SNS+Lambda+IAM) | 10 minutos (dashboard + DNS) |

| Portabilidad | Cero | Completa — HTML estático en build time |

| Mantenimiento continuo | Coste operativo oculto | Prácticamente cero |

| Control de versiones | No disponible | Git nativo |

El email transaccional ha sido durante demasiado tiempo un punto ciego en la arquitectura de software. Elegíais un proveedor y os olvidabais — hasta que queríais cambiaros y descubríais que no podíais.

La próxima vez que alguien os diga que "Resend es caro" o que "solo vale para startups", recordad esto: el coste real del email no es el precio por mil envíos. Es el coste de no poder iros cuando queráis. SendGrid y SES os cobran en libertad lo que ahorráis en céntimos por email. Resend os devuelve esa libertad.

*Resend no es el destino final. Es la llave para salir de la cárcel. *

Migrad las plantillas primero. El proveedor puede esperar.