“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.

When it comes to both transactional and triggered email, many software teams assume that the logical next step is to start building their own notification system. But moving down this path without a clear view of the complexities and the size of the undertaking might not be the best solution for your business.

Sending transactional emails isn’t as simple as you may think

Email notifications are crucial to delivering important information from your product. They also have the potential, when designed well, to drive deeper user engagement. However, building your own triggered email notification system is more complicated and a bigger project than you might realize.

As examples, take a look at LinkedIn’s Air Traffic Controller or Netflix’s cross-platform in-app messaging orchestration service. These were both massive ventures, even for these enterprise-level organizations.

While it might start with a simple “Let’s send an email,” it soon becomes an ever-growing list of ongoing development tasks. Sending via SMTP will impact the performance of your page. To counter this, you will need to implement a job queue fairly soon. And, especially if it’s critical in nature, you’ll need to verify that your email has been delivered. As volume grows, you may end up sending multiple types of emails, each with its own template, trigger, and level of importance (and send priority). How long before you need to look into the detail of sending logs, tracking each type of email for each user, and dealing with spam reports?

You’d be better off unlocking immediate value — especially if you are at the crucial early stage of bringing your SaaS offering to market — by buying this functionality from an established third-party provider. This has the added advantage of freeing up your engineering team to focus on what matters most: building up your core product.

5 features an email notification system should include

An email notification system sits between events that occur in your application — like the creation of new accounts, a subscription renewal reminder, or a booking confirmation — and the message that it triggers (in this case, an email notification).

Here are five key features you’ll need to consider when implementing an email notification system.

1. Fast integration with an email service provider

An email service provider can help with delivering the notifications, managing anti-spam, tracking, and reporting. However, each provider has a different interface and API, with unique formatting requirements, rules, and limitations that you will need to cater to.

Being able to quickly change or add providers over time, without needing to rewrite and test tons of code — think design once, deliver to many — will help you ensure deliverability of your critical emails and prevent an overreliance on a single provider or channel.

2. Easy templating and template management

Coding templates from scratch and storing them in your codebase will create an ongoing overreliance on your engineering team. Rather, give your product and marketing teams control over content creation by managing your templates outside of the source code.

Providing a visual design editor will empower them to create and update email templates, ensuring a consistent look and feel across all your email notifications, without the need to constantly change code.

3. Intuitive orchestration

Workflow orchestration needs to be intuitive to use and, again, sit outside your codebase. This will make it easier for your product manager to adapt as your rules around triggered events change. Creating new notifications, linking the event to the message, and setting the delivery rules and notification channels through workflows rather than code means you don’t have to wait on the dev team every time.

4. The ability to respect recipients’ preferences

Respecting your customers’ communication preferences — allowing them to control what notifications they receive and on what channels (for when you need more than email) — might sound like a nice-to-have luxury for the future. Consider, though, what engagement outcomes you are trying to drive, such as strengthening interaction with your customers and avoiding your email being marked as spam.

Receiving, storing, and respecting your customers’ preferences are critical to not abusing their 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, product design lead at Quora, in a Medium post on the topic of notification design.

5. Robust logs and sage retry mechanisms

Sometimes emails don’t get delivered as smoothly as we’d like. To ensure high deliverability success, you need:

• An idempotent retry mechanism to safely retry send requests without accidentally spamming your recipients.
• The means to interpret and reconcile the various delivery statuses, normalizing these across the email service providers, to provide yourself with the flexibility to change and add as needed. Because each service provider has its own rules and formatting, this can quickly become a challenge.

Questions to ask before deciding to build vs. buy

When it comes to custom software development, the internet is full of build-versus-buy advice. You probably read much of this when determining whether it was a good idea to build your own product. Does the same conclusion still hold true in building out an email notification system capability? For example, if you needed an internet payment capability, would you build it or use an existing service, like Stripe?

With an email notification system, there are some additional questions you should ask yourself before deciding.

What are your business goals?

Consider what you want to achieve, not only with your own product offering but also with your email notification capability. Will creating a bespoke notification service for your product be critical to achieving those goals, or would buying provide the same, or better, results?

• Is this core functionality, or a standard service?
• Are the problems you are trying to solve unique to you, and will they give you a competitive advantage, differentiating you in the market, or have they already been solved?
• Is there an expected ROI that only a bespoke solution can deliver or is it an additional overhead?
• Can you wait on the development, or would you benefit from the functionality now?

Do you have a clear view of the scope?

While you might be starting with triggered email notifications now, do you have a clear view of your future requirements? Be honest about the scope, as this can quickly become a lot more complex as you add more teammates, more notifications, and more communication channels.

• Are you willing to put the same plan, design, build, and test efforts into your notification infrastructure as you put into your core offering?
• How about future enhancements and capabilities? For example, what value would Slack or Microsoft Teams direct message integration offer to your customers in the B2B SaaS space?
• What about the ongoing maintenance of your email service? Are you willing to give up engineering resources to update templates or manually code new ones?
• How committed are you to creating the required functionality? If you only build to solve one or two short-term problems in your code now, you are likely to end up with an ongoing overreliance on your developers.

Can you afford the cost and the time?

Building a custom solution has higher up-front costs than buying off the shelf. That’s before you even factor in “the hidden costs” of software development.

So ask yourself:

• Can you afford the initial investment, and do you need the additional control and flexibility that custom-built solutions provide?
• How static or dynamic will your notification messages, templates, and workflows need to be? Can you afford to allocate the resources of a dedicated team for ongoing development and maintenance efforts to meet your product manager's changing needs? Will this give you the best return on effort?
• Are you aware of the opportunity costs, i.e., what is the impact of diverting some of your engineering team’s focus to building out functionality not core to the service you provide?

The benefits of buying a notification system

A dedicated, purpose-built notification solution like Courier addresses the key features discussed above. In addition, you get immediate benefit from a host of advanced capabilities that are unlikely to ever get prioritized in a custom-built solution. Advanced capabilities such as:

• Reusable templates that you can manage outside the source code, with a drag-and-drop visual editor that will empower the product team so they won’t have to rely on developers for each and every tweak.
• Applying a consistent look and feel across your notifications, even for white labeling email notifications for multiple brands or customers.
• Multichannel functionality to easily incorporate push notifications, SMS, and direct messaging, in addition to your triggered email notifications.
• The ability to quickly design and create notification workflows to interact with your users according to their communication preferences and your delivery rules (think right user at the right time over the right channel).
• Direct, prebuilt integration with leading communication providers across email, push, SMS, and direct messaging, giving you flexibility and redundancy.
• Optimized deliverability with built-in retry mechanisms and scale — on infrastructure that’s purpose-built for high-volume delivery.
• Actionable insights out the box so you can track and measure performance, delivery success, open rates, and click-throughs from the start.
• Quickly test different channels and service providers, measuring the impact on your notification strategy.

If you are still in the early stages of bringing a SaaS solution to market, these benefits are probably even more important to you. If you start building your own notification system now, committing many hours and creating processes around it, then you’re going to be hesitant to rip it out later, regardless of how well it performs or meets your needs.

If, however, you start with a dedicated third-party solution, then you immediately get access to more than triggered email notifications. You get to learn at a lower risk and, thanks to the consumption-model pricing structures, at a lower cost, too.

If you later find that you have unique needs or need full control, you can always switch to building your own without much loss of money or time. More importantly, though, your development time was focused in the right place at these crucial early stages — getting your core functionality to market.

Buying a triggered email notification system will give you a competitive advantage

A DIY solution will leave you slow to leverage critical functionality that a purpose-built notification system delivers from day one. Buying a notification system will empower your product team from the start, making it easy for them to implement new opportunities to engage with your users quickly.

Not only will this improve your customer interaction, but it will also free up your engineers to focus on building out core functionality and getting unique features to market.

Start building notifications for your app with Courier’s free developer plan, which includes 10,000 notifications every month. Sign up for free, or join our Discord Community to learn more.