Build vs. buy for transactional email notifications

"Transactional email is complex, and for most teams, it's a tedious afterthought rather than a first-class citizen," according to Postmark, an email API provider.

For both transactional and triggered email, building your own notification system can look like the natural next step. For most products, buying is the better call: build only if how and when you notify people is what customers pay you for. Before you decide, get a clear view of how big the job is.

Sending transactional emails isn't as simple as you think

Email notifications carry the most important information your product sends, and well-designed ones drive engagement. The system that sends them is a bigger project than it looks.

LinkedIn's Air Traffic Controller and Netflix's cross-platform in-app messaging orchestration service show how big it gets. Both were major projects, even for companies that size.

It starts with "Let's send an email." Then sending over SMTP inside a web request slows that request down, so you add a job queue and send in the background. Critical emails need confirmation that they were delivered. Volume grows, and soon you're sending many types of email, each with its own template, trigger, and priority. After that come send logs, tracking each type of email for each user, and handling spam complaints.

Buying this from an established provider gets you all of it on day one and keeps your engineers on your core product.

6 features an email notification system should include

An email notification system sits between events in your application (a new account, a subscription renewal reminder, a booking confirmation) and the emails they trigger. Here are the six features it needs.

1. Fast integration with an email service provider

An email service provider handles delivery, anti-spam, tracking, and reporting. But each provider has its own API, formatting requirements, rules, and limits that your code has to handle.

If you can add or switch providers without rewriting and retesting your code (design once, deliver to many), you protect the deliverability of your critical emails and you don't depend on a single provider.

2. Easy templating and template management

Templates coded into your codebase mean every wording change needs an engineer and a deploy. Manage them outside the source code instead, so your product and marketing teams own the content.

A visual editor lets them create and update email templates and keep a consistent look across all your email notifications, without touching code.

3. Intuitive orchestration

Orchestration is the logic that links an event to a notification and sets its delivery rules and channels. Keep it out of your codebase, too. In a visual builder, your product manager can create notifications and change the rules as your triggered events change, without waiting on a deploy.

4. The ability to respect recipients' preferences

Letting customers choose which notifications they get, and on which channels once you send more than email, can look like a nice-to-have for later. It isn't. If the only way to stop an unwanted email is the spam button, people use it, and those complaints hurt the emails they do want.

Storing and honoring those choices is how you keep your customers' trust. "Notifications are an incredibly powerful tool for a product person to wield that often get underused or abused to maximize short term gains," said Henry Modisett, then a designer at Quora, in a Medium post on the topic of notification design.

Some notifications aren't optional, though. A password reset or a security alert has to arrive, so your preference system needs to tell required notifications from optional ones and refuse an opt-out on the required kind. The law draws a similar line: the FTC says transactional or relationship email is exempt from most CAN-SPAM requirements, while marketing email needs a working opt-out.

5. Safe retries and delivery logs

Sends fail, and your retry policy has to handle the everyday causes:

• Losing connectivity to your email service provider, or an outage on their side.
• Hitting provider rate limits.
• A network drop right after you send but before you get confirmation, so you can't tell whether the email went out.
• Delayed, asynchronous responses from providers that tell you whether delivery succeeded.

Retries also have to be safe. With idempotent requests and deduplication, a retry never emails the same notification twice.

Then you need to see what happened. Each provider reports status in its own format, so normalizing statuses gives you one view of which notifications were delivered, over which channel, and through which provider. You also need to know what each stage of the delivery lifecycle means: queued, sent, accepted, rejected, bounced, delivered, opened or clicked, unsubscribed, and spam complaint.

6. Tracking that tells you the truth

To understand the impact of your email notifications, you need to track what recipients do with them. That's harder than it looks.

Open rates are a rough signal. Open tracking relies on an invisible image that some email clients block, so it isn't entirely reliable. Click tracking rewrites every link to pass through a redirect, and some spam filters are wary of a shared tracking domain. You end up deciding which links to track (deep links into a mobile app are the usual ones to skip, since a redirect can stop the phone from opening the app) and whether to put your own domain in them.

Past that, your product team needs reporting per notification, so they can improve content, timing, and priority based on what recipients actually do.

When to build and when to buy

If you needed to take payments, you'd use an existing service like Stripe rather than build one. Notifications work the same way.

Build only if notifications are your product, meaning how and when you notify people is what customers pay you for. The LinkedIn and Netflix systems above show how big that investment gets. If your product is something else, buy. Your needs will also grow past one email: more templates, more channels such as Slack and Microsoft Teams, more teammates who want to change wording without a deploy. Each of those becomes a project your engineers own for as long as the product exists, and every hour spent on it is an hour not spent on your core product.

The benefits of buying a notification system

A notification platform like Courier covers all six features above, plus a few that rarely make a homegrown roadmap:

• Reusable templates outside your source code. Design Studio is a visual editor where your product team drags blocks onto a canvas and edits wording after you ship, so they don't need a developer for every tweak.
• A consistent look and feel. Brands cover white-labeling, so you can style notifications for multiple brands or customers.
• Multi-channel from one template. One template holds the email, SMS, push, in-app, Slack, and Microsoft Teams versions of a notification.
• Multi-step flows. Journeys is a visual builder for multi-step flows (delays, branches, batching, digests), so the product team changes delivery rules without a deploy.
• Preferences that Courier enforces. Users opt in or out per topic and pick their channels, and required topics always deliver.
• 50+ provider integrations with automatic failover. Courier retries transient provider errors, then moves to the next provider on the channel, then to the next channel, so one provider's outage doesn't stop your password resets.
• Safe retries. Send an Idempotency-Key header and a repeated request returns the first result instead of sending again.
• Logs and tracking. Every message moves through one set of statuses in the logs, and open and click tracking is built in.

This matters most early, while you're still bringing your product to market. Build your own notification system now, put hours and processes around it, and you'll hesitate to rip it out later, however well it works.

Start with a platform instead and you get more than triggered email from day one, you pay per message as you grow, and your engineers stay on what counts at that stage: getting your core product to market.

Start building notifications for your app with Courier's free Developer plan, which includes 10,000 messages a month. Sign up for free.