The Hidden Costs of Building Your Own React Notification System

Allie Dyer Bluemel Last updated on September 27, 2024

Organizations with active service development will be familiar with the build vs. buy conversation. You have to weigh the time and human effort of building and maintaining a custom solution over that of implementing and maintaining a third-party tool.

The scaling of a feature might not be at 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.

The request for a new feature like a React notification system (or Vue, or Svelte) might seem simple on the surface, but as your core product or service grows, so does the need for increased data governance and automation.

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.

The complexities of a React notification system

On the surface, notification systems might seem simple to implement.

For very small products and applications, this might actually be true. If a product has no plans to scale and there’s no concern about using notifications to grow the user base directly, a custom build might be a viable option. But for products that have regular or ambitious growth plans, or there’s a need for notifications to engage users, there are myriad complexities to a React notification system.

These complexities could come to light after developers start building, delaying the feature and delaying other features that were depending on its completion. Unanticipated roadblocks, like compatibility with certain browsers, operating systems, and devices will derail production timelines.

If what needs to be built is a small pop-up notification system based on some simple user-triggered events, a full solution might be sustainable as front-end-only React notification components. As soon as you introduce another layer of complexity, however, such as integrating user data or saving notifications to be viewed later, the solution requires a lot more technology.

OneSignal has 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

While integrating a handful of libraries into a custom solution and manually managing device tokens might not seem like a huge task for some teams, others will prefer the smaller task of maintaining and updating a third-party solution. Services like OneSignal and Firebase Cloud Messaging exist because they fill a very real need for organizations to offload the responsibility of building and maintaining a system requiring device tokens and provisioning certificates.

Custom solutions take devs away from feature tasks

The general consensus of most build-versus-buy articles is: While rolling your own solution might be the right choice for some companies, for the most part, it’s more cost-effective to buy a tool (or implement a free one) whose only focus is to build the solution to the problem you have.

If notifications are a core part of the overall product, it’s probably easy to justify removing developers from other feature tasks to focus solely on notification systems.

But if a notification system is a small feature of the overall product, the time and human effort costs to implement a custom solution probably aren’t worth it. That said, collaboration software and workflow tools can benefit immensely from a reliable notification stack provider.

The Pros of a custom build

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.

In any case, it makes sense to get closely familiar with all the nuances of React Notifications build before you start.

The Cons of a custom build

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.

Unless notification is a simple pop-up message that requires no database or the need to save user data, data privacy and user consent need to be in the conversation. Consent to gather or store user data is no longer something that’s important for companies to consider because it’s becoming mandatory.

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.

While some companies might protest these regulations, other 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.

The cost of compliance and consent isn’t so hidden. 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 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.

Being compliant can be worrisome for a business of any size. 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.

Let MagicBell handle your workflow notifications

MagicBell is on a mission to get notifications out of your email inbox and into your app. Workplace notifications are an important part of communication, but you shouldn’t have to build your own system to keep people up to date.

Let MagicBell handle your workflow notifications while you handle the parts of your business that are driving growth.