The blocker is payment, not product
Worth saying plainly: if you can pay Resend, Resend is a great choice, and their React Email tooling has no equivalent here. We are not going to pretend otherwise.
What we offer is the same job — authenticated transactional email from your own domain — payable with UPI, netbanking or a domestic card, prepaid one month at a time so nothing auto-renews against a card you would rather not keep on file.
How the two are shaped
| Email4VibeCoder | Resend | |
|---|---|---|
| Billing currency | INR | USD |
| Payment methods | UPI, cards, netbanking, wallets (Razorpay) | International card |
| Renewal | Prepaid one month at a time, never automatic | Subscription, renews automatically |
| Over your limit | Temporary SMTP error, retry safely. No overage charge, ever. | Overage billing or a hard stop, depending on plan |
| How you send | Plain SMTP, ports 587 and 465 | HTTP API, SDKs, and SMTP |
| Lock-in | None — it is four settings you can repoint anywhere | Some, if you build on the API and templates |
| Authentication | DKIM signing, SPF alignment, TLS | The same |
| Delivery visibility | Per-message log with the receiving server's own reply | Dashboards, event webhooks, analytics |
Plan sizes and prices change on both sides — ours are on the pricing page, theirs on theirs. This table is about how each service works, which changes far less often.
Moving an app across from Resend
Resend supports SMTP as well as its API, so if you were already using smtp.resend.com it is a settings change:
- SMTP_HOST=smtp.resend.com
- SMTP_USER=resend
- SMTP_PASS=re_xxxxxxxx
+ SMTP_HOST=smtp.email4vibecoder.com
+ SMTP_USER=your-username
+ SMTP_PASS=your-password
SMTP_PORT=587Coming from the SDK, the send becomes a Nodemailer call. React Email still works, by the way — render your template to an HTML string and pass it as the message body:
import { render } from '@react-email/render';
import nodemailer from 'nodemailer';
import WelcomeEmail from './emails/welcome';
const transporter = nodemailer.createTransport({
host: process.env.SMTP_HOST,
port: 587,
auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },
});
await transporter.sendMail({
from: process.env.MAIL_FROM,
to: '[email protected]',
subject: 'Welcome aboard',
html: await render(<WelcomeEmail name="Ada" />),
});Then verify your domain under Domains and publish the DKIM record. Keep the Resend records in place until you have switched over — extra DKIM selectors do no harm, and they let you move back in a minute if you change your mind.
When Resend is the better choice
- React Email. Writing templates as React components, previewed locally, is a real advantage and it is theirs.
- A first-class HTTP API and SDKs. If you prefer an API call to an SMTP connection, or your host blocks SMTP ports, that settles it.
- Batch sending, scheduling, webhooks, audiences. Product surface we do not have and are not trying to build.
- Reputation at scale. More volume, more IPs, more history.
We would rather you know that now than discover it after moving. If any of the above is how you work, stay where you are.
What you give up here
- No HTTP send API. SMTP only. Every framework speaks it, but if your platform blocks outbound SMTP ports entirely, an API-based provider is your only option.
- No template editor, no campaign tools, no open tracking. This is plumbing for application email, not a marketing platform.
- One sending region, and a young sending reputation. A large provider has years of history across thousands of IPs. We are building ours, carefully, which is why the acceptable-use rules here are strict.
- A small team. Support is email, and it is a person, not a rota.
Trying it without committing
The free plan sends 500 emails a month on one domain and needs no card, so the honest way to evaluate this is to point a staging environment at it for a week and read the delivery log. Nothing auto-renews, and there is no subscription to cancel afterwards.
Create a free account, or read the integration guide first.