4 Ways to Send Notifications to a Mobile Phone

Dennis Kean — Wed, 22 May 2024 20:21:54 +0000

If you are building a notification service for your product and wondering how to send notifications to your users via their smartphones, we will discuss 4 solutions for sending mobile notifications.

For a brief overview, here is a table including quick comparison points for our given solutions:

	SMS	Mobile Push	Web Push	3rd-Party Social Apps
Cost	Most expensive option	One-time cost for app store listing	No cost	No cost
Time	~Weeks of compliance approvals	~Days of app development + approval time	~Hours, no 3rd-parties	~Days to integrate 3rd-parties
User Experience	Simple, fast and direct	Must download app, flexible design	Must opt-in, rigid UI	Easy to use, rigid UI

SMS

SMS is a direct way to send notifications to others. Accessible through 3rd-party services, you can integrate notifications via text messages into any project. This will require the designated user’s mobile number, and setting up a plan with services capable of SMS communications such as NotificationAPI, Twilio, etc.

Some drawbacks to consider when approaching SMS notifications are:

Making sure notifications feel important
Requires users to trust you with mobile numbers
At large volumes, it will be costly
Notifications must follow 10DLC compliances & regulations (NotificationAPI handles these for you)

Mobile Push

Mobile Push offers a great way to deliver notifications to your audience. Through your app, users can opt-in to notifications without divulging personal phone numbers. If your service is already app or mobile-oriented, getting users to opt-in for updates should have a higher conversion rate than projects or services that don’t rely on mobile at all.

While Mobile Push notifications may sound ideal, developers who haven’t already published an app can find this approach costly and drawn out - here’s why:

Developing an app for Apple and Google’s app stores
Sending push notifications requires creating and managing device tokens (NotificationAPI handles this for you)
Having a mobile app creates expectations of other app functionalities from your end-users

Web Push

Web Push might be the most approachable method for those looking to build their own notification system. Its straightforward design lets users create basic notifications either on their own or through integrating 3rd-party services. Developers can skip building an app or purchasing an SMS service plan, saving both time and money. Users can opt-in by simply visiting your website on their phone and allowing Push notifications when prompted. These web push notifications look similar to app notifications but offer less flexibility and options.

Web Push is a viable solution for mobile notifications, however, there are some minor cons worth mentioning:

This requires your users to first visit your website and allow Push Notifications
You need to generate device tokens in your front-end and store them in the back-end (NotificationAPI does this for you)
These notifications are easily dismissed and forgotten without a dedicated inbox (NotificationAPI offers an in-app notification inbox)

Other Social Apps (Slack, WhatsApp, Telegram)

Using 3rd-party communication apps allows for free integration of notifications through apps your users may already use. These apps are already well optimized for user experience so they look and feel good to use.

Having great UX at no cost are good enough reasons to consider 3rd-party apps for notifications, though there are still some downsides:

For apps like Slack, it takes time to develop and integrate your server/channel
Similar to Mobile Push, using 3rd-party apps generates the expectation of more than just notifications

Conclusion

Picking the right approach depends a lot on the platforms your company aims to support. For example, if your software is only going to be accessible through a web interface, then SMS and Web Push Notifications are viable options. If you have plans for a mobile app, then mobile app notifications are certainly the right way to go. If you believe most of your users will integrate your software into existing apps, then you may want to consider the last option.

Ultimate Guide on Notification Services - A Technical Overview (2024)

Dennis Kean — Wed, 01 May 2024 20:34:30 +0000

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:

	Build	Buy with NotificationAPI
Upfront Engineering Cost	Weeks to Months	Days
Cost	50% less	Check our Pricing
Upkeep	5% of your engineering capacity over time	~0%, Most tasks can be handed off to CS/Design

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:

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.

DEV Community: Dennis Kean