Do you need a 3rd-party notification service? In this article, we review the challenges of a typical notification project and review the viable solutions.

Motivation

Until a few years ago, the only way to build product-to-user notifications in SaaS products was to build them from scratch. This came with a few problems.

The business case against building notifications

If you have ever tried to prioritize a notification project in a growing tech company, you have experienced the following:

Similar to Authentication, notifications are "utility" features. They don't generate revenue, don't have a place on your pricing page, or excite end-users. So it's difficult to get buy-in from your team to prioritize notifications. However, they are necessary for users, and when implemented poorly - just like authentication - they blow up in your face with bugs, downtimes, frustrated users (LaunchDarkly, Starbucks), and poor DX.

Generally, after a few important clients request notifications or some bad reviews on G2Crowd, notifications make it to your roadmap.

The problem with building notifications

There is nothing technically complicated about building notifications. It's just that there is so much nuance and gotchas that most people don't think about. Some of these are technical considerations, and some are more relevant to UX:

General considerations:

• Integrating to a 3rd-party, e.g. email, Slack, WebSocket

• Respecting the 3rd-party API Rate Limits, implementing job queues and retry mechanisms, e.g. SendGrid

• Implementing user preferences and opt-outs (why is this important?)

Email specific considerations:

• Monitoring bounces/reports/complaints to avoid being suspended

• Account/Company verification and higher API limit requests - example stories

• Designing and coding HTML email templates

• Batching, e.g. weekly digests, and all of its necessary infrastructure (database, cron, job runner)

• Google bulk email sender requirements (learn more)

In-App specific considerations:

• Database, REST APIs, and optionally WebSocket

• In-App inbox UI

• UI-side batching, e.g. "You have 10 new comments" vs. ten separate "You have a comment" notifications

SMS/Calls:

• Brand/Campaign approval (A2P 10DLC Registration)

• Country-specific regulations and registrations And more... I know what you are thinking:

Do I actually need all this complexity?

TLDR: Are these notifications part of a growing software where people rely on them? Then, the answer is yes.

You fall in this category if you are building a production-grade SaaS product or internal automation where notifications are an important part of the workflow, e.g. scheduling, review and approval, collaboration, communication, monitoring, or alerting. This means your notification requirements are already complicated or are going to grow in complexity as your business and client base grow.

If you don't fall into this category, you can safely close this tab, code something together, and move onto more important things in life.

If you fall in this category, let's learn more about:

Notification Services

Definition: A notification service facilitates implementing, sending, and monitoring product-to-user notifications. It consists of tools and APIs to design notifications, configure workflows, manage user preferences, deliver to the inbox, logging, and analytics. It could be a 3rd-party Notification-as-a-Service like NotificationAPI or implemented internally as a microservice.

How about marketing notifications?

Let's differentiate between:

Product: (or product-to-user) notifications, which this article is mainly about, are generated from the codebase and are specific to a user or a client.

Promotional: announcements or engagement baits that are always sent to all or many users at once. They don't need to be initiated from the codebase.

These two categories of notifications have different triggers (product vs. business) and goals, and are managed by different teams. Avoid combining them into the same system. Use a CRM for promotional notifications. Build or buy a notification service for product notifications.

Build vs Buy

Fun backstory:

In a different life where I was the CTO of a growing VC-backed B2B SaaS company, our notification system was the bane of our existence. The notification database would frequently fail to scale with our users and cause outages; nobody was happy with the notification UX, users complained in G2Crowd reviews. Even developers were not happy with the DX and everyone wanted to replace it. "There must be a 3rd-party for this", so I googled the words "Notification API" and found nothing. Am I missing something here? Isn't this a big enough problem? I queried our task management software and found that notifications made up 5% of our whole Done tasks. We had spent 5% of our WHOLE productivity on something that had to be replaced. Having found no proper solution, NotificationAPI was born a few years later.

We haven't done a formal study, but here are some anecdotes:

• Speaking to CTOs, architects and PMs who are considering NotificationAPI instead of building from scratch, they generally foresee their in-house project to take 4-8 weeks, at about half the cost of NotificationAPI in infrastructure and 3rd-party tools

• Speaking to our customers who adopt NotificationAPI [1, 2], they tell us that we have saved them weeks to months of work, in line with the above estimation

• Talking to some CTOs who already have an in-house notification system in place, it seems like 5% is a good estimation of the engineering effort they put into maintaining their notification system (1 in 20 tasks)

So in summary and based on anecdotal experience:

Requirements to think about

Whether you are building or buying a Notification Service, think about the following requirements:

Functional:

• Supported Channels & Platforms, e.g. Email, In-App (bell), Mobile Push, Web Push, SMS, Automated Calls, Slack/Teams, Desktop

• Batching/Digest to avoid frustrating users with notification overload

• User Preferences to let end-users decide how and what they receive

• Visual Editors to let your designers/CS teams build the notifications

• Logs for your CS team to find sent notifications and figure out why a user hasn't received a notification

• Analytics/Reporting for your PMs to improve the notification experience

If everything is important, then nothing is important. Too many notifications for a user is equal to having no notifications at all. No user is going to scroll through 50 notifications. That's why batching, digest and user preferences are very important in a busy application.

Technical:

• Language or framework-specific SKDs

• Pre-built UI components for in-app notifications (the bell icon), notification preferences pages, unsub pages

• Retention: How long are notifications and logs stored?

• Scalability: Consider your peak time output and their

• Availability

• Compliance (SOC2, GDPR, HIPAA)

• Migration: How are you moving all the user preferences and existing in-app notifications to a new service?

Implementation Options

Below are all the options we could think of in order of taking the least amount of effort & risk to the most:

1) NotificationAPI

We built NotificationAPI to plug into your software as your own product-to-user notification system. We believe it's a good fit for growing B2B SaaS products with multiple types of notifications. It does the following for you:

• Designing Notifications: pre-built UI components, visual template editors

• Simple Implementation: comes with user preferences, batching & digest, and other logic & databases you would normally implement yourself

• Delivery: actually delivers the notification to the destination without requiring any other 3rd-parties (with the exception of mobile push which Google/Apple have a monopoly over)

• Post-Release: customer success tools, logs, and analytics

Pros: low effort, low risk, UX, DX

Cons: cost

2) Notification Infrastructure

Think AWS SNS paired with AWS Step Functions or any glorified rebranded versions of them. They help with some of the challenges, but they don't address the majority of the project: notification design, delivery, rate limiting, user preferences, notification batching, monitoring, etc. We believe this middle-ground inherits the problems of both build and buy options without much to offer.

Pros: control

Cons: cost, effort, stack fragmentation

3) Building from Scratch

Viable option depending on your tolerance for the effort and time. We have written a few articles that might help:

• Notification service architecture design (Serverless version here)

• Common non-technical mistakes with building a notification system

• Common technical mistakes

• Hidden scalability bottle-necks with notifications

Pros: cost, control

Cons: effort, DX

TLDR

Consider a notification service if your notifications are part of a growing software (B2B SaaS, important business automation) where people rely on them (collaboration, communication, alerting, monitoring, approvals, reviews). Otherwise, just roll your own.