Mailchimp for SaaS

A large share of SaaS companies under $5M ARR run their email on Mailchimp, usually because it was already there when the first marketer arrived. Most advice tells them to migrate immediately. That advice is often wrong, and always expensive.

Mailchimp does several things a SaaS team needs, competently and cheaply. It also has four limits that are genuinely hard, and knowing which one you are about to hit is more useful than a generic recommendation to switch.

What does Mailchimp do well for SaaS?

Three things, and they cover more of a young company’s needs than people admit.

Newsletters and announcements. The editor is good, the template system is reasonable, deliverability on shared infrastructure is solid, and a non technical person can ship a send in twenty minutes without breaking anything. That is not a small thing when your marketing team is one person.

Simple welcome automations. A four email welcome series triggered on list join, with basic tag based branching, works fine. If your onboarding email is essentially “here is how to start, here is a case study, here is a call link”, Mailchimp sends it.

Cost at small list sizes. Under 2,000 contacts the free and entry tiers cover a lot. A seed stage company running a newsletter and one welcome flow has no financial reason to move.

A lifecycle stage setup that works

If you are staying on Mailchimp for now, structure it this way from the start.

That setup will carry a company to roughly 15,000 contacts and a few thousand users without much pain.

The four hard limits, with their symptoms

Each of these has a specific way it shows up, and none of them are fixable with a better integration.

Limit	Symptom you will notice	Severity	Workaround lifespan
Audience based pricing	Bill rises faster than list growth; duplicate contacts across lists	Medium	Permanent if you use one audience
Weak event handling	You cannot send an email when a user hits a usage limit	High	None for real time needs
No account object	Ten seats from one customer look like ten strangers	High	Partial, via an account name merge field
Limited branching	Journeys flatten into parallel campaigns you maintain by hand	Medium	Holds to about 3 branches

Weak event handling

This is the one that ends the relationship. Mailchimp’s native event richness lives in its ecommerce integrations: orders, carts, products. For a SaaS product, your events are hit_usage_limit, invited_teammate, payment_failed, project_created, and there is no first class place to put them with their properties intact.

What you end up doing is converting events into tags. hit_usage_limit becomes a tag, a journey starts on that tag, and the email goes out. It works. What it cannot do is carry the properties: which limit, at what number, on which plan. So the email has to be generic, and a generic limit email converts far worse than one that says “you are at 4,812 of 5,000 records”. The difference between those two emails is most of the value of the whole freemium upgrade programme.

Latency is the second half of the problem. Tag based triggers plus a nightly or hourly sync means your limit email arrives hours after the block. That email needs to arrive in under two minutes.

No account object

Mailchimp has contacts. It does not have a company or account record that contacts belong to. Every SaaS reporting question you care about is account shaped.

Symptoms: you cannot suppress a whole account when it opens a support ticket. You cannot report engagement by customer. You cannot send the admin a different email than the end users on the same subscription. You cannot tell that three of your unsubscribes last month were all from one churning enterprise customer, which is the signal you most wanted.

The workaround is an account_name merge field plus saved segments, which gets you clumsy suppression and no reporting. It holds to maybe 200 accounts.

Workarounds that hold up, and for how long

Some of these are genuinely fine. Others are the thing you will be apologising for in a year.

Hold up well:

• One audience plus tags for lifecycle, plan and persona. Clean, cheap, stable.
• The API for stage changes at nightly cadence. Simple and reliable for anything not time sensitive.
• Saved segments as suppression lists, applied as a default exclusion on every campaign.
• Transactional email sent entirely elsewhere, through your own provider, never through Mailchimp campaigns.

Hold up badly:

• Usage numbers in merge fields. They desynchronise, they truncate, and numeric comparison in Mailchimp segments is limited. This is the clearest single sign you have outgrown the tool.
• Tag bands to fake numeric segmentation, such as seats_1_5, seats_6_20, seats_21plus. You now have a nightly job rewriting tags, and every band change is an API call. At a few thousand accounts you hit rate limits.
• Parallel campaigns imitating branches. Three journeys that should be one, drifting apart every time someone edits only one of them.
• Zapier chains firing tag updates per event. Works at 50 events a day, falls over at 5,000, and costs more than the email tool.

The five migration signals

Any two of these together and I would move. One alone is usually survivable for another year.

1. You need real time product event sends. Usage limits, activation moments, payment failures. Latency of hours is not acceptable and no workaround fixes it.
2. You need account level reporting or suppression. Someone asked which customers are disengaged and you could not answer.
3. Your journeys need more than three branches. You are maintaining five near-identical campaigns because the builder cannot express one flow.
4. You are syncing usage data through merge fields. Already past the line. The only question is whether you move this quarter or next.
5. You need marketing and transactional sending fully separated with independent reputations. You have grown enough that a bad campaign genuinely threatens your password reset delivery.

Add a sixth that is about the organisation rather than the tool: nobody on the team can explain what the tag trial_2024_v2 means any more. Accumulated cruft in Mailchimp is a real migration trigger, and a migration is often the cheapest way to delete it.

Cost comparison at 10,000 and 50,000 contacts

Pricing moves, so treat these as a shape rather than a quote, and check current published pricing before deciding.

The headline: at 10,000 contacts Mailchimp is cheapest, but not by enough to matter, and it is the only row with a No in the last column. At 50,000 the gap narrows to roughly the cost of one contractor day a month, which is far less than the cost of maintaining tag bands and nightly syncs.

That is the honest economic case. You are not migrating to save money. You are migrating because the workarounds consume more engineering time than the licence difference, and because the emails you cannot send are worth more than the emails you can. Model the upside with the SaaS email revenue calculator before committing a quarter to the move.

For the fuller shortlist including enterprise options, SaaS email marketing platforms compared covers the field, HubSpot versus Customer.io is the decision most teams actually face, and Marketo for SaaS or Mautic for SaaS cover the enterprise and self hosted ends respectively.

What the migration actually costs

Four to six weeks of part-time work for a small team, and it is heavier than vendors suggest.

The work: re-instrumenting events properly, rebuilding every journey, remapping tags to a real data model, warming a new sending domain over two to three weeks, and running both systems in parallel for a fortnight to catch gaps. Expect to lose some historical campaign reporting, because it rarely transfers cleanly.

The thing nobody warns you about: your engagement metrics will look worse for about six weeks on the new domain while reputation builds. Tell your leadership before it happens, or the migration gets blamed for a dip that is entirely expected. Churn prevention sends are the ones to hold back during warming, since they matter most and tolerate delay least, as covered in churn prevention email campaigns.

The verdict

Stay on Mailchimp if your email is newsletters, announcements and a welcome flow, your list is under 15,000, and no email you want to send depends on what happened in the product in the last hour.

Move when two migration signals are lit. And if you are already writing nightly jobs to push usage numbers into merge fields, you crossed that line some time ago and the workaround is now the project. Benchmark whatever you build next against the SaaS email benchmarks rather than against what Mailchimp’s dashboard called good, and keep the rest of the programme design consistent with the SaaS email marketing hub.