Nuestra recomendación, de entrada. Creamos Proxy Mail QA, y casi nada de esta lista es nuestro. Recomendamos Proxy Mail QA para un solo hueco: si tu sitio tiene registro, inicio de sesión o restablecimiento de contraseña, o envía correos de cuenta como invitaciones, te da bandejas de entrada de prueba para comprobar que esos correos funcionan. Si tu sitio no tiene cuentas ni envía correo, no lo necesitas, y el resto de esta guía sigue siendo válido.
La lista
| Necesitas | Para qué sirve | Opciones comunes |
|---|---|---|
| Un lugar donde escribir o generar el código | Crear el sitio | Un editor como VS Code o un IDE de Qoder; un agente de programación de IA como Qoder, Claude Code o Cursor; o, sin código, un constructor como Webflow, Framer, Squarespace o WordPress |
| Control de versiones | Deshacer errores, trabajar con otros, desplegar | Git, con GitHub o GitLab |
| Un framework (opcional) | Páginas, rutas y datos sin empezar desde cero | Next.js, Astro, SvelteKit, Nuxt |
| Alojamiento | Poner el sitio en internet, con una vista previa para cada cambio | Vercel, Netlify, Cloudflare Pages, Render |
| Un nombre de dominio | Tu propia dirección y el dominio de envío del correo | Cualquier registrador; DNS en el registrador o en Cloudflare |
| Registro e inicio de sesión (si la gente tiene cuentas) | Cuentas, contraseñas, códigos y enlaces mágicos | Supabase Auth, Clerk, Firebase Authentication, Auth0, Auth.js, Better Auth |
| Una base de datos (si guarda algo) | Cuentas, pedidos, contenido | Postgres (Supabase, Neon), Firestore, SQLite |
| Un proveedor de correo (si envía correo) | Correos de verificación, restablecimiento y recibos, desde tu dominio | Resend, Postmark, Amazon SES, SendGrid, Mailgun |
| Pagos (si vende) | Tarjetas, suscripciones, facturas | Stripe, Paddle, Lemon Squeezy |
| Analítica | Saber qué usa la gente | Plausible, PostHog, Google Analytics |
| Seguimiento de errores | Saber qué falló antes de que te lo digan los usuarios | Sentry |
| Pruebas | Saber que un cambio no rompió el registro ni el pago | Playwright o Cypress para el navegador; Vitest o Jest para el código; Proxy Mail QA para los correos |
| Herramientas de revisión | Velocidad, accesibilidad, enlaces, SEO | Lighthouse, axe DevTools, un verificador de enlaces, Google Search Console. Más en herramientas para crear y revisar mi sitio web |
| Páginas legales | Política de privacidad, términos, aviso de cookies cuando haga falta | Redactadas para tu sitio y para donde están tus usuarios |
Lo que puedes omitir
- Un sitio sin cuentas (un portafolio, un café, una landing page): un constructor o un framework, hosting, un dominio y analítica. Un servicio de formularios si quieres recibir mensajes. Sin autenticación, sin base de datos, sin pruebas de correo.
- Una tienda: una plataforma de tienda alojada como Shopify puede cubrir hosting, pagos, cuentas y correo en un solo lugar, y pruebas lo que te deja cambiar.
- Una app con cuentas (un producto SaaS, una comunidad, un sitio de reservas): casi toda la lista. Lo que más se olvida es la configuración del proveedor de correo y las pruebas de los correos.
Dónde encaja Proxy Mail QA
Cuando la gente puede registrarse, tu sitio envía correos que tienen que funcionar: el código o enlace de verificación, el restablecimiento de contraseña, la invitación. Fallan de formas que otras pruebas no detectan. Un enlace apunta a localhost, el proveedor sigue en modo sandbox y no envía nada, o salen dos correos en lugar de uno.
Proxy Mail QA te da una dirección de prueba nueva y privada para cada intento, extrae el código o el enlace y revisa cómo se envió el correo. Puedes usarlo a mano en el navegador con Proxy Mail QA for Chrome, en pruebas de Playwright o Cypress con su paquete de npm, o desde un agente de IA como el de Qoder a través de su MCP server. El plan gratuito incluye 500 direcciones de prueba en total.
No construye, aloja ni diseña nada, y no envía correos por tu sitio: sigues necesitando un proveedor de correo.
Un primer stack para una app con cuentas
Una forma de armarlo, si construyes con Qoder:
- Código: el agente de Qoder, en un repositorio Git en GitHub.
- Framework y hosting: Next.js en Vercel, con un despliegue de vista previa para cada rama.
- Cuentas y datos: Supabase, para registro, inicio de sesión y la base de datos.
- Correo: Resend, enviando desde tu propio dominio. El correo integrado de Supabase solo envía a tu propio equipo, unos pocos por hora, así que configura tu propio proveedor de correo antes de que se registre alguien más.
- Errores: Sentry.
- Pruebas: Playwright para el flujo de registro, con Proxy Mail QA para el correo de verificación, ejecutadas en cada despliegue de vista previa.
Cualquier fila se puede cambiar por otra de la tabla. El orden importa más que las marcas.
El orden para configurar todo
- Compra el dominio pronto. Los proveedores de correo lo necesitan para enviar con tu nombre, y los registros DNS de SPF, DKIM y DMARC pueden tardar en propagarse.
- Configura el repositorio y el hosting con despliegues de vista previa, para que cada cambio tenga un enlace que puedas probar.
- Agrega cuentas y correo a la vez. Verifica tu dominio de envío con el proveedor y sal de su modo sandbox, o tus correos de verificación solo te llegarán a ti.
- Prueba el registro en una vista previa antes de compartirla: una dirección nueva, el correo llega, el enlace va a la vista previa y no a
localhost, y la cuenta funciona después. - Agrega analítica y seguimiento de errores antes del lanzamiento, no después de la primera queja.
Si construyes con Qoder, puedes conectar Proxy Mail QA desde el Qoder Marketplace y pedirle al agente que revise el correo de registro después de cada cambio en tu código de autenticación. Cómo funciona.