Cambiar idioma:

Resend: por qué ha llegado a donde está y por qué lo uso en cada proyecto - 04/03/2026

Hay herramientas que uno prueba una vez y ya no puede imaginar trabajar sin ellas. Resend es una de esas herramientas. Explico qué hace diferente a Resend, por qué su apuesta por la developer experience los llevó a dominar un mercado que parecía resuelto, y por qué lo uso en cada proyecto.

El mercado del email transaccional antes de Resend

Enviar emails desde una aplicación parecía un problema resuelto. Había opciones establecidas: SendGrid, Mailgun, Amazon SES, Postmark. Todas funcionales. Todas con documentación extensa.

También todas con el mismo problema: estaban diseñadas para equipos de empresa, no para desarrolladores individuales.

La experiencia típica:

Crear una cuenta, verificar MX records, SPF, DKIM…
Navegar una consola con decenas de opciones que no necesitas
Buscar en Stack Overflow cómo enviar tu primer email
Construir templates en un editor visual desconectado de tu código
Debuggear bounces con logs difíciles de leer

Funcional. Doloroso.

Qué hizo Resend diferente: la apuesta por DX

Resend llegó con una premisa simple: el envío de emails debería ser tan simple como una llamada a función.

import { Resend } from 'resend';

const resend = new Resend(process.env.RESEND_API_KEY);

await resend.emails.send({
  from: 'Acme <onboarding@acme.com>',
  to: ['user@example.com'],
  subject: 'Welcome to Acme!',
  react: <WelcomeEmail userName="John" />,
});

Eso es todo. Sin configurar SMTP. Sin servidor de correo. Sin plantillas en HTML crudo.

Pero lo que realmente los diferencia no es la simplicidad de la API. Es la coherencia de la decisión de priorizar DX en absolutamente todo.

Las decisiones de DX que los llevaron al éxito

1. React Email: templates como componentes

Resend co-creó React Email, una librería para construir templates de email con componentes React. Esto cambió radicalmente el flujo:

// WelcomeEmail.tsx
import { Html, Body, Heading, Text, Button } from '@react-email/components';

export function WelcomeEmail({ userName }: { userName: string }) {
  return (
    <Html>
      <Body>
        <Heading>Bienvenido, {userName}</Heading>
        <Text>Estamos felices de tenerte con nosotros.</Text>
        <Button href="https://app.example.com">Comenzar</Button>
      </Body>
    </Html>
  );
}

Los templates viven en tu repositorio. Se versionan, se testean, se refactorizan como cualquier componente. Sin editor visual externo, sin HTML spaghetti.

2. Documentación que respeta el tiempo del desarrollador

La documentación de Resend muestra cómo enviar tu primer email en menos de 5 minutos. No en teoría: en la práctica. Hay ejemplos para Next.js, Remix, Express, FastAPI, Laravel — con el stack exacto que probablemente estés usando.

3. SDK moderno, tipos incluidos

El SDK de Resend está escrito en TypeScript. No como afterthought: como decisión de diseño. Cada respuesta está tipada. Cada error tiene forma predecible. El autocompletado funciona.

const { data, error } = await resend.emails.send({ ... });

if (error) {
  // error.name, error.message — tipos específicos, no `any`
  console.error(error.name);
}

4. Dashboard legible

El dashboard muestra exactamente lo que necesitas: logs de envíos, estados de entrega, bounces, y nada más. Sin ruido. Sin pestañas que nunca usas.

5. Pricing que no castiga a los indie developers

Hay un tier gratuito generoso (3,000 emails/mes, 100 emails/día). Sin tarjeta de crédito para empezar. Sin “surprises” en la factura.

Por qué lo uso en cada proyecto

Cuando empiezo un proyecto nuevo, el email transaccional es infra que no quiero pensar. Necesito:

✅ Emails de bienvenida
✅ Confirmación de cuenta
✅ Reset de contraseña
✅ Notificaciones de actividad
✅ Facturas y recibos

Con Resend, todo eso está resuelto en horas, no días. No pierdo tiempo configurando infraestructura de email. Escribo un componente React, llamo a la API, y listo.

En Keppli Finance y en capturioo.com Resend maneja todos los emails transaccionales. Nunca tuve que pensar en deliverability, en bounces, en queues. Simplemente funciona.

La lección de negocio detrás de Resend

Resend no inventó el envío de emails. Reinventó la experiencia de enviar emails para desarrolladores.

Su crecimiento no viene de tener más features que SendGrid. Viene de que un desarrollador que lo prueba nunca quiere volver a usar otra cosa. Eso es retención basada en experiencia, no en lock-in. Es el modelo correcto.

En un mercado commodity, la DX es el moat.