Your own SES vs a managed email platform

Both give you transactional and marketing email with React Email templates, broadcasts, and automation. The difference is who owns the sending infrastructure, where your data lives, and how the bill grows. This comparison is most useful for three kinds of teams:

• teams on Resend whose per-email and per-contact bills are growing faster than their product
• teams already on AWS who want marketing email, segments, and workflows without a second sending stack
• teams deciding between “managed platform” and “platform on infrastructure I own”

Sending architecture

Whose infrastructure carries your email

When you send with Resend, your email travels through Resend's infrastructure — shared IPs by default, with a dedicated IP available for $30/mo. Your sending reputation is built inside their platform, and your contacts and email data live with them. For many teams that's exactly the appeal: one vendor, zero infrastructure, sending in minutes.

SendOps takes the opposite position. It installs into your AWS account via CloudFormation, and every email it sends — transactional, broadcast, or drip workflow — goes out through SES in your account, on a sending reputation that belongs to you. Your domains, your configuration sets, your suppression data, your event history: all in an account you control.

Neither model is wrong. But if email is core to your product, owning the layer it depends on is a real difference — not a feature-checklist one.

Cost at volume

Per-email pricing compounds. Flat pricing doesn't.

Resend's transactional tiers, at list prices as of July 2026, run from a free 3,000 emails a month through $20/mo for 50,000 and $90/mo for 100,000 — genuinely cheap at small scale. But the meter keeps running: at 1M emails a month you're at roughly $650/mo, and it grows from there.

SES charges $0.10 per 1,000 emails. The same 1M emails cost about $100 in raw SES delivery, and SendOps adds a flat $29/mo (Team) or $149/mo (Business) on top — the platform fee doesn't change with volume, and the Free plan has no volume caps either. Call it ≈ $129/mo versus ≈ $650/mo at 1M, with the gap widening as you grow.

At low volume the difference is noise, and Resend's free tier is a fine deal. The question is what your bill looks like at the volume you're growing into, not the volume you started at.

The contact meter

Marketing email bills twice on Resend

Sending isn't the only meter. On Resend, marketing contacts are priced separately from email volume: free up to 1,000 contacts, then — at list prices as of July 2026 — $40/mo per 5,000, $250/mo per 50,000, and $650/mo per 150,000. Broadcasts only go to contacts stored in the platform, so a growing audience means a growing storage bill on top of sending costs.

SendOps doesn't meter contacts on any plan, including Free. Your audience lives in your own AWS account, so there's no platform storage to charge for. A 50,000-contact list is $250/mo of storage on Resend's list pricing — and $0 on SendOps. Automations follow the same pattern: Resend includes 10,000 runs a month, then $0.0015 per run; SendFlow workflow runs aren't metered.

If your list is small, none of this matters yet. If you're building a real audience, the second meter deserves a line in your projection — especially because it bills for storage, not sending. Good email practice is a large list you mail selectively; on a contact meter, the leads you responsibly don't email still cost you every month. Flat pricing means keeping every lead costs nothing until you actually send.

Templates

Both sides speak React Email

Credit where it's due: React Email is Resend's open-source framework, and it's become the standard for writing email templates as typed React components. SendOps supports React Email authoring too. If you have templates today, they're portable in either direction — a genuinely shared standard.

The difference is what happens after you write them. On Resend, templates are managed through their editor and API and rendered on their infrastructure. On SendOps, your TSX lives in your own repository and custom converters compile it to the Handlebars templates SES runs natively — the deployed template has no runtime dependency on anyone. When someone edits one in the visual editor, the change comes back as a pull request: the same review, history, and rollback as the rest of your codebase, with an asset CDN and tracking domains handled for you. The full authoring reference is in the SendOps React Email docs.

Ownership and control

Your account, your reputation, your exit

The ownership model is where the two products diverge most sharply:

With Resend, the platform is the infrastructure — your reputation, contacts, and email data live inside it. That's a reasonable trade for the simplicity it buys, but it means leaving is a migration project. With SendOps, leaving is removing a stack; your email keeps flowing through SES exactly as it did the day before.

The program as code

Segments and workflows your repo — and your agents — can read

Both platforms cover the marketing feature set. Resend has broadcasts to stored contacts and automations, managed through a polished dashboard and API. SendOps has SendQL segments, broadcasts, and SendFlow drip workflows — defined in a plain-text DSL with a visual canvas on top, and layered with deliverability analytics, an activity API, and a public API v1.

The structural difference is that on SendOps, the definitions themselves are code in your repository. A segment is a SendQL expression you can diff. A drip sequence is a SendFlow file you can review. A template is TSX. That means a coding agent can propose a new onboarding sequence, adjust a segment, and update the template it references — all in one pull request, with a human approving the merge. The whole email program becomes something your existing engineering workflow can operate, with guardrails built in.

If your email program is run by people clicking through a dashboard, both models work. If you want it operated like the rest of your codebase, only one of them is built that way.