What it actually costs to move your email templates to another provider

A company I used to work for sent all of its transactional email through Mandrill (now Mailchimp Transactional). Password resets, invoices, reports, notifications. We used it for years and it worked, so nobody touched it.

The problem was not the sending API. The problem was where the templates lived. This post is about that, and about what I would do differently today.

How templates end up inside the provider

Mandrill, like Postmark and Amazon SES, lets you store a template on their side. Your code sends a template name and a few variables, and the provider renders the email. It sounds like a good deal. The HTML is out of your codebase, and in theory marketing can edit it without you.

So the first template goes there. Then the next one. A few years later every email the product sends is a template in someone else's database, and your code only knows the names.

What it cost us day to day

Two things hurt, and neither of them was the price.

Every change needed a developer. The editor was there, but in practice nobody outside the dev team used it. A small copy change became a ticket. The ticket waited until a developer had time. Then the developer opened the template, made the change, tested it, and published. A one line fix could take a week, not because the work was hard, but because it had to wait in a queue.

Finding the right template was painful. With a large number of templates in a flat list, searching and navigating was awful. Names were inconsistent because they had been created by different people over several years. There was no history beyond "draft" and "published", so you could not see who changed what or roll back a bad change. Opening three templates to find the one you need was normal.

None of this is a Mandrill bug. This is what "templates as a provider feature" looks like after a few years.

What it cost us when we wanted to leave

Three things pushed us to look around.

The product stood still. From where we sat, almost nothing changed for years. The editor, the template list and the API looked the same as when we started. We were not alone in that feeling. In 2019, during a Mandrill outage that lasted more than 30 hours, the person who opened the HN thread wrote that the service "hasn't had an update to any of its features since it merge with Mailchimp" (HN, 2019). Meanwhile the rest of the email tooling moved on. When the tool you depend on stops moving, you start to wonder how long it will exist at all.

We were locked in. Mandrill is an add on to a paid Mailchimp account, so we paid for Mailchimp without using it. Templates were in Mandrill's own dialect, with their merge tags and their editor markup. The longer we stayed, the more templates there were to convert later.

The price stopped making sense. Mandrill sells email in blocks of 25 000 for $20, on top of a Mailchimp Standard plan from $20 a month. At 50 000 emails a month that is about $60. Resend charges $20 for the same volume, and that includes the API, webhooks and a template workflow built around code. We were paying three times more for a tool that was not improving. (Prices checked on 2 November 2026 on each provider's pricing page.)

A few things surprised us.

The export gives you HTML in Mandrill's dialect. Merge tags like *|FIRST_NAME|* and mc:edit attributes have to be rewritten for whatever renders your email next. Conditionals do not map one to one.

We had never rendered our emails outside Mandrill. So there was no set of test payloads, no expected output, nothing to compare against. We had to build that first.

And the real cost was never a line in the budget. It was developer hours spent on copy changes and on finding things, and nobody added those up.

This is not new. In that same 2019 thread the author put the whole problem in one sentence.

"Looking to change service providers soon, as soon as we figure out how to render emails to html before sending." (adnans, HN, Feb 2019)

If the provider renders your templates, you cannot leave until you can render them yourself.

To be fair to Mandrill in 2026

Since April 2026 templates built in Mailchimp's visual builder publish straight to Transactional. The editor is better than the one we used. What has not changed is that templates still live on their side, there is still no version history, and the export is still in their dialect.

Three ways to keep templates out of the provider

1. Templates in the repo

React Email, MJML or plain HTML files next to your code. You render at send time and pass html to the provider instead of a template name.

import { render } from "@react-email/render";
import { PasswordReset } from "./emails/password-reset";

const html = await render(<PasswordReset url={resetUrl} name={user.firstName} />);
await provider.send({ to: user.email, subject: "Reset your password", html });

You get versions in git, code review and tests. Changing provider is a one file change.

You pay with deploys. Every copy change goes through a developer, which is exactly the problem we had. For a small team with ten templates this is still the right answer.

2. Templates in your own database

Store MJML or HTML in your database and render it yourself. Put any editor in front of it, GrapesJS, Unlayer or a plain textarea.

You get editing without deploys and no provider lock in.

You pay by maintaining an email editor. Versions, preview, test sends, merge tag checks, Outlook bugs. That is a product, not a feature. We looked at it and did not do it.

3. A separate template layer

A service that only does templates, versions and triggers, and sends the result through the provider you already use. Customer.io and Braze do this, plus a lot more, and charge per contact. Senlo, which I am the author of, is an open source version of this layer. It has an MJML editor, version history and triggers, and it sends through your own Resend, Postmark, SES or SMTP account. Dittofeed and Waypoint are other options in the same space.

You get non developers editing emails and developers calling one endpoint with a template id.

You pay with one more service to run. The honest test is simple. Do people who are not developers change your emails more than once a month? If not, option one is cheaper.

If you are choosing a provider today

Decide where the templates live before the first one is created. Make it a place you can render from without the provider. The sending API is a commodity. The templates are what you will still be untangling years later.

If you have moved templates off Postmark or SES, I would like to hear what broke for you.

Originally published on senlo.io. Senlo is open source (AGPL-3.0): github.com/IgorFilippov3/senlo.