Buying a complete notification stack VS building one

You have to weigh the time and human effort of building and maintaining a custom solution over implementing and maintaining a third-party tool. In this section, we'll help you to make the right decision.

Organizations with active service development will be familiar with the build vs. buy conversation.

Scaling of a feature might not be on the forefront of these early conversations. But any feature that is meant to engage users and increase usage will need to scale as a part of the growth process, and this process should be discussed early on.

Scale, timeline, and human effort

Implementing a feature like a notification system might seem simple, but as your core product or service grows, so does the need for increased data governance and automation.

Pitch is on a mission to make the best presentation software. That means collaboration is at the core of what they do, and MagicBell's notification inbox is the heart of this collaboration!

OneSignal created a formula to break down the hidden costs of a complete custom-built notification system:

Cost to Build = Initial Build Time (months) + Hosting Costs for Various Device Types + Cost to Maintain + Cost of Updating for Every Software Update + Cost of Adding Features (e.g., A/B Testing, Segmentation, Prompting Subscribers) + Building and Maintaining Security + Opportunity Cost

In an ideal world, time and cost aren’t an issue and stakeholders, managers, designers, and developers would have deep planning conversations before implementing a new feature like a notification system.

The reality is a new feature will likely be on a limited timeline, with only so many resources available to get it done. With so many third-party tools out there providing solutions for these types of features, the case for a custom build becomes harder to justify.


An easily identifiable benefit of a custom solution is full control over design, customization, and implementation. Even if notifications aren’t a core part of the product, companies that have a strong brand and visual identity might not acquiesce to the easy implementation of a third-party tool that limits customization.

Creative directors and designers alike probably have strong opinions about how notifications should tie into the identity of the brand. Discussing long-term plans for a notification system is where the cost analysis needs to be introduced to make an informed decision about the time and effort it will take to maintain such a system.

In addition to design, another type of customization is platform compatibility. Insights into what operating systems and devices users access the product with can inform decisions about prioritizing what to build for.

If your product is a mobile-only app with considerable usage on Android but minimal usage on iOS, it could be worth building a custom solution that tailors specifically to those users, with the intention of focusing on other uses as they become a larger part of your user base.


Developers already spend significant time maintaining and testing code rather than working on new features. A highly involved custom notification system would increase the amount of time needed for testing before release.

As a product scales, a user base grows, and engagement increases, the reliability of a notification system needs to stay intact. If there’s little to no automation built into the process, this is where testing and debugging can eat up a lot of developer time.

With a third-party tool, the automation, testing and debugging responsibility shifts from developers to the third party, relieving developers of non-core product-related duties.

It’s safe to say developers won’t throw the prevailing tech stack out the window to custom build a notification system. If your back end is Rails, and your front end is React, you’ll most likely end up with a Rails and React notification system.

If a few years down the road, a decision is made to switch the tech stack to Node and Vue, the custom solution will have to be overhauled.

A third-party tool whose whole business is notifications is likely to have an SDK or implementation process that works with a variety of tech stacks, meaning updating them is exponentially easier.

“It’s safe to say developers won’t throw the prevailing tech stack out the window to custom build a notification system.”

While Safari desktop and iOS versions support the Service Worker API, Safari on iOS isn’t compatible with Notifications API (which we’ll talk about soon). In addition, no version of Safari supports the Push API. The Push API can be implemented to send notifications to users even if your web app isn’t loaded. To achieve push notifications even when the web app isn’t loaded, Safari provides its own solution for desktop users. If you want to implement notifications with the Push API, you need to take into account having a separate implementation for Safari desktop.

Notification API VS Push API

Regardless of if you expand beyond in-app and push notifications, these two notification types require different technology to get to customers. There needs to be consideration for the work that will need to go into building out and maintaining a system for each one. Even if we break down notification systems further into just one type — desktop push notifications — there are still some fundamental choices to be made. You can push notifications to your users if they’re on your web app, or you can push them to your users even if your web app isn’t loaded. But these two types of notifications don’t have the same support and require different implementations.

Notification API

The Notifications API lets you send out notifications to those who have your web app loaded, regardless of whether it’s focused. Not only should you get permission from users before you start sending them messages, but you also need to be careful about how you go about it.

Browsers have started blocking web apps from requesting permission in a spam-like manner, as well as those who continue to request even after a user has denied permission. This API is pretty straightforward: user has web app open, request permission, send notifications.

Push API

The Push API is probably very exciting to marketers and strategists alike. With it, after receiving permission, you can send notifications to users even if your web app isn’t loaded.

This allows you to send marketing, sales, and promotional content whenever you want. Unlike mobile push, which is universally accepted as a way of life at this point, web push, in the same manner, is not. The support for this type of web push is low, meaning it’s only effective if your customers happen to be using the various browsers and devices that support it.

Building Compliant Notifications


The GDPR and the CCPA are great for a user’s information security, and the trend would suggest more measures will be put in place to protect the user. For instance, Apple is making waves by updating its privacy settings to allow users more control over how their data is used.

Companies genuinely want to be compliant, but might not have the resources necessary to make sure all aspects of the business are regulated properly.

While large corporations and social media companies are scrutinized more heavily than smaller businesses, everyone needs to be careful about abusing user data, even accidentally.


Even if your organization isn’t located in Europe, if your user base includes people residing in Europe, GDPR compliance is mandatory. The same is true for California. If your user base includes people residing in California, regardless of where your organization is located, CCPA compliance is mandatory.

A GDPR violation can result in a twenty million euro fine, and the cost of CCPA violations result in equally hefty fines. The future of responsible tech will revolve around companies needing to justify and explain to users why their personal identifying information needs to be collected and what it’s being used for.

Now might be the time to reassess what data you actually need to be taking from your users.

While most notification systems will require some form of consent, push notifications take more work to be fully compliant.

With push notifications requiring tokens and provisioning certificates that a user can revoke at any time, keeping those updated can be a headache in a custom solution. Whether you opt for a custom solution or want to integrate a third-party tool, it’s crucial to know who is ultimately responsible for the storage and maintenance of the user’s data, and how much time and effort it costs to be compliant.

We’re not saying every third-party tool is GDPR and CCPA compliant, but this is also a consideration that needs to be taken into account when figuring out the scale and timeframe of a project like this.


Unless notifications are your core business, buying is your best option

The biggest benefit a third-party tool is going to give you is the ability to offload a lot of the responsibility of notification system architecture.

Third-party tools provide you with full solutions with their APIs and SDKs, often with ways to tailor the experience to your business—if you have the capacity to take on more work.

While your core product may not be tied to notifications, notifications are the core product of notification tools. The people behind these tools are constantly working to improve their product and add features that will help you utilize notifications.


Next: how to design thoughtful notifications