Same Amazon SES economics. No server to run.

Sendy is beloved for good reason — it made SES-priced email marketing accessible years before anyone else, and it's still actively maintained. This comparison isn't about whether Sendy works. It's about what running it actually costs, and what a platform built on the same foundation looks like in 2026. It's most useful for three kinds of teams:

• teams running Sendy today who like the SES economics but not the server that comes with it
• teams paying a hosting service to run Sendy for them
• teams choosing between a one-time self-hosted license and a managed platform on the same SES foundation

The self-hosting tax

The real price of Sendy isn't $69

Sendy's list price is a one-time $69 license, and on that line item nothing competes. But the license is the smallest part of the bill. Running Sendy means running a server: PHP and MySQL to install and patch, cron jobs to keep alive, backups to verify, and scaling to handle when your list grows. Commonly cited pain points in public reviews are exactly these — the setup is technical, and the maintenance never really ends.

The clearest evidence is that an entire hosting sub-industry exists just to run Sendy for people — monthly-priced services whose whole job is absorbing the server ops. If you're paying one of them, you've already converted Sendy into a subscription; the question is only which platform the subscription buys.

SendOps removes that layer entirely. There is no server, no PHP, no MySQL, no cron. You keep your SES account — the part actually worth keeping — and SendOps runs everything else. The Free plan is $0 with unlimited volume and no contact limits, which is less than any VPS.

Automation depth

Autoresponders vs lifecycle workflows

Sendy's automation is autoresponders: time-based drips that fire on a schedule after signup. For welcome sequences and simple nurture emails, they work — and for many newsletters that's genuinely enough.

SendFlow is a different category. Workflows are multi-step, branching, and triggered by events and contact activity — a signup, an attribute change, an open, an action your application reports through the activity API. You author them as a plain-text DSL or on a visual canvas; both are views of the same workflow. Waits, conditions, and branches let you build lifecycle programs — onboarding, re-engagement, expansion — that respond to what a contact actually does, not just when they joined.

The same gap shows up in segmentation. Sendy offers condition-based segment rules. SendQL is a query language over your contacts, attributes, and email activity — expressive enough to define the audiences your workflows target, and stored as plain text you can version.

Analytics and alerting

Reports tell you what happened. Alerting tells you before it hurts.

Sendy gives you campaign reports — opens, clicks, bounces, unsubscribes per send. That's useful, but it's backward-looking, and it's where the analytics story ends. A commonly cited limitation is that there's no deliverability monitoring: if your bounce rate creeps toward SES's thresholds, Sendy won't tell you.

SendOps treats deliverability as a first-class concern. Bounce and complaint rates are monitored continuously, deliverability analytics show trends across domains and sending identities, and alerting notifies you before a problem becomes an SES pause. On a platform where the SES account is yours — and its reputation is yours — this is the layer that protects the asset.

Everything as code

Templates in git, segments as queries, workflows as text

In Sendy, templates live in a drag-and-drop editor or as pasted HTML, and configuration lives in the app's MySQL database — which means none of it is something an AI coding agent can read, diff, or improve; a drag-and-drop editor was a convenience in 2015 and is a dead end in the agent era. In SendOps, template source is React Email TSX in your own git repository — edited in the SendOps UI or your editor, with PR write-back so every change is reviewable — and SendOps compiles it to the Handlebars templates SES runs natively. Images and assets ship through a built-in CDN.

The same is true across the platform: SendQL segments and SendFlow workflows are plain text. That makes them diffable and versionable — and it makes them operable by coding agents. An agent can write a segment, adjust a workflow, or open a PR against a template the same way it works on the rest of your codebase. A public API v1 and activity API cover the rest.

Architecture and ownership

Closer to Sendy's ethos than any SaaS ESP

Sendy's current pitch is "Send Newsletters Without SaaS Lock-In," and the instinct behind it is sound: your sending infrastructure and your data shouldn't be hostage to a vendor. SendOps takes that instinct seriously — which is why it's architected differently from a conventional ESP:

Your SES account, your domains, your sender reputation, and your templates (in your git repo) all remain yours. If you leave, the sending infrastructure doesn't move — because it was never ours. That's the ownership Sendy users actually care about, without the server that Sendy attaches to it.

Migrating from Sendy

Stop hosting Sendy. Keep everything that matters.

Because both tools sit on your own SES, moving off Sendy isn't an email-provider migration — the sending layer doesn't change at all. Your SES account stays exactly as it is. SendOps connects to the same account through a two-minute CloudFormation setup and imports your existing verified domains and configuration non-destructively. Your sender reputation, built over years of Sendy sends, carries over untouched because it was never Sendy's to begin with.

From there: export your Sendy lists to CSV and import them as contacts, rebuild segments in SendQL, and recreate autoresponders as SendFlow workflows — usually gaining triggers and branching in the process. When the last campaign has moved, you decommission a server instead of a sending history.