How to Add a Notification System to your MVP

As a product engineer, you likely understand the value of incorporating notifications functionality into your Minimum Viable Product (MVP).

Here's what you can accomplish by building notifications:

Drive engagement. Notifications inform customers that there’s something going on in your application that’s worthy of their attention. Timely notifying your audience about valuable content or interactions with other users is great for building trust and engagement.

Enable user journeys based on asynchronous actions. If you don’t expect your users to always be connected to your app or service, notifications enable your users to stay plugged in without having to constantly check for updates in-app.

Support time-sensitive operations. Perhaps you’re planning on requiring two-factor authentication at login, or maybe you simply want to let account admins know each time somebody new first signs into their workspace. In both cases, adding real-time notifications can help call attention to time-sensitive details where needed.

At the MVP stage, developers focus on finding product-market fit for their venture. On the one hand, this means experimenting with functionality that’s capable of creating value. On the other hand, teams at this phase start requiring less and less time on every new experiment, before finding something that works.

In this article, we show you how to build a notification system for your MVP, in a way that both enables experimentation and helps you get results quickly.

Let’s dive in!

The main components of a notification system

We’ll start by reviewing a very simple notification system for an application:

mvp-stage notification system
Architecture diagram for a simple notification system.

This simple system, though functionally limited, still has certain key components that enable its extensibility to future use cases: a set of notification triggers, a central place for all notification-related decision logic, a simple templating system, and connections to various messaging providers.

Let’s walk through the components and show what a simple implementation for each part would look like in JavaScript. We’ll begin on the diagram’s right, where the elements are more specific, and will work towards the left, where components become more abstract.

Email dispatch via an email API

Sending an email through an email API is straightforward: we connect to an email provider using its JavaScript SDK, form the message with the parameters required, and then send the message.

In this example, we’ll work with AWS SES as the email provider—but you would get a similar result if you're working with another provider.

First, we’ll need to install the AWS SDK:

$ npm install aws-sdk

We can then use the SDK to send an email through SES:

// notify.js

var AWS = require('aws-sdk');
AWS.config.update({region: 'us-east-2'});
var ses = new AWS.SES();

function notify_email(subject, message, email_address) {
  var params = {
        Destination: { ToAddresses: [ email_address] }, 
        Message: {
            Body: { Text: { Charset: "UTF-8", Data: message } }, 
            Subject: { Charset: "UTF-8", Data: subject }
        }, 
        Source: "[email protected]", 
  };
  ses.sendEmail(params, function(err, data) {
    if (err) console.log(err, err.stack);
    else     console.log(data);
  });
}

In this example, we send a text-only email and skip the HTML version. We hard-code the source address as we assume that all emails will come from the same sender on our side. All of these assumptions can be changed in the future as our product expands.

Message templates

We can now send emails, but it’s going to be unviable to handcraft every email at the various codebase locations from which notifications can originate.

Message templates are a pattern that lets you easily parameterize your notifications with user data. Here’s our simple templating “system”:

// notify.js

function template_activity(channel, props) {
    switch (channel) {
        case 'email':
            return `Hello ${props['first_name']}, there is an interesting post that you can check out here:

                            https://disc.world/activity`
    }
}

Instead of going with string literals, we can use more functional solutions like mustache.js once we need to send more complex notifications.

In the above example, however, we’ve generated just one template. Templates for HTML emails, push notifications, or chat notifications could follow in the same function.

Notification decision logic

With email sending and templates out of the way, we now need to make decisions on whether we should notify users about a given event. The simplest approach to this task is a function that switches between notification types based on the parameters being passed in:

// notify.js
function maybe_notify(event, props) {
    switch (event) {
        case 'activity':
            // todo: check notification preferences
            // todo: check unsubscribe list
            console.log('Sending activity notification to user:', props['id']);
            notify_email(
                'Something interesting on the Discworld!',
                template_activity('email', props),
                props['email_address']
            );
    }
}

Our function selects the right template and messaging medium based on notification type, and also creates a log message so that we can debug any issues.

You might not always want to notify someone of new activity, so we’ve added a few TODOs to check for preferences and monitor our unsubscribe list.

Notification trigger

Finally, we need to wire everything together and send an activity notification:

// notify.js

maybe_notify('activity', {
    'id': 123,
    'email_address': '[email protected]',
    'first_name': 'Rincewind'
});

In our example, the function is accessible directly in our JavaScript file, but if you’re accessing notifications through various services, this might happen over an HTTP or RPC API.

Running the example

To run the example, we ensure that our AWS account is configured and then run node notify.js:

$ node notify.js
Sending activity notification to user: 123
{
  ResponseMetadata: { RequestId: '751ecac5-d140-4717-a06a-94b3b42d01ef' },
  MessageId: '010f017a15621a86-ac305fa4-919a-4178-8362-7faf64e10cc8-000000'
}

And we can see the resulting email in our email client:

The resulting email in our email client.

While this is a very simple notification system that’s quick to set up, it still includes key components that you'll be able to build on top of when your MVP moves forward to the next stage.

What should you leave out of an MVP-stage notification system?

With an MVP-stage system, the goal is to make your notifications sufficiently functional for all sides without over-allocating time to make that happen.

This doesn’t mean that you should save on error handling and unit tests, however. Our recommended approach for an MVP-stage notification system is to keep the initial amount of functionality that the system offers limited while keeping its quality high, following best practices, and thoroughly testing all code paths.

Let’s expand on that.

Features to exclude from an MVP

To help you decide which features should go into an MVP-stage notification system, think about what you’re trying to achieve with your MVP.

You’ve likely already defined one or more metrics for the MVP’s success (if you haven’t, you should consider doing so!). For a new product, let’s assume that you’re measuring the number of daily active users.

How do notifications tie into the daily usage metrics? If you build a good-enough notifications system, how will that help you achieve your goal?

In our example, a notification will likely be the mechanism by which your product’s users can learn about something that needs their attention. If they haven’t signed in on a particular day, a notification is the only way to alert them to the activity they missed. In such a scenario, we could very well attribute the sending of a notification to a direct increase in daily active users (DAUs).

Now, how you build your notifications will affect your system’s impact on DAUs. Going from zero notification channels (no notifications at all) to one channel (e.g., email) can significantly boost your MVP metrics.

But would adding a second channel (e.g., mobile push) make enough of a difference?

That depends. Your app’s functionality may rely on real-time interactions, in which case a push notification on the user’s phone will make a difference compared to an email notification that might get read later on.

But if you’re building a B2B application where synchronous action has less importance, then having email notification only will probably suffice.

Here are a few examples of features to potentially exclude from an MVP if they don’t directly drive the MVP’s metrics:

Additional notification channels.

Aditional types of notifications.

Non-essential efficiency and performance improvements.

What you shouldn’t skip even in an MVP system

Even if you’ve decided on the specific functionality that’s critical to your MVP’s success, there are still a few things that you should keep in mind for any MVP-stage system. Regardless of the MVP notification system you're building, here are some guidelines to keep in mind:

Item 1: Polished experience for a limited set of notifications. Typos in your notification templates; incorrectly functioning call-to-action buttons; email designs that don’t work on mobile—these are all issues that will affect the sentiment of your early users. Although you'll be working with a limited number of notification channels, the ones that you do select for your MVP should contribute to a positive user experience. Spend a bit of time on testing and validating (manually and/or automatedly) the look and feel of your MVP notifications.

Item 2: Right notification, at the right time. The reason why you’re building notifications in the first place is to alert your users to an event that merits their attention. It’s important to get the mechanics of your notifications right, especially when you’re only using one or a few notification channels in your MVP. Document the overall logic for when a notification should and shouldn’t be sent, and make sure that you keep this logic consistent throughout your application.

Item 3: Reliability and consistency. Few things are more frustrating than notifications getting sent inconsistently. If your MVP system accidentally skips so much as 10% of the notifications that should have been sent, your users might miss out on app interactions and eventually decide that your notifications “don’t work” and simply disable or ignore them. Building trust with your early users is critical, so consider implementing monitoring for your notifications system. You need to be able to identify issues before they can cause any negative impact.

Common gotchas when building MVP notification systems

By this point, you’ve hopefully settled on the functionality that you’ll include in your MVP notification system. Here are a few common pitfalls that startup engineers should avoid when building basic notification systems.

Shortcuts taken now can be painful in the future

While we encourage taking certain shortcuts in the MVP phase—like having an initially reduced number of supported notification channels, it’s important to consider how the choices you make today can impact what’s possible for your product down the line.

For example, modeling all of your messages around a particular email API can make it more difficult to change email providers or add SMS support in the future.

We recommend that you come up with your own schema for what a notification object should look like. Implementing this level of abstraction will make it easier to add other notification types in the future.

Remember that you’re serving multiple categories of users

Notification systems aren’t only used by your customers. You, as a developer, are also a user of the system. And if the system constantly breaks, your team will suffer setbacks.

Your content editors and marketing team will most likely want to change individual notifications and tweak the text. These colleagues might not have the technical know-how to edit the code base and submit pull requests.

When building an MVP system, reflect on how the notifications experience will look for all customer groups, both internal and external. The experience for each group doesn’t need to be perfect (and probably can’t be perfect in an MVP), but if you’re prioritizing one group’s experience over another, make this choice explicit and discuss it with your team.

You won’t go far without deliverability

Notifications that aren’t delivered do not fulfill their purpose and do not move your metrics in the right direction. Any operational issues with your notifications system can affect deliverability, but there are other factors to consider.

For email notifications, having the right DKIM and SPF records set up for message authentication can improve the likelihood of emails getting to your users’ inboxes.

For mobile push notifications, delivery may be prevented due to connectivity issues or the user’s device being off. Retrying a push message a few times if delivery fails can increase the rate of successfully delivered notifications.

Quickly build an MVP-stage notification system with Courier

Building an MVP notification system from scratch need not be overly complicated. We encourage you to think through the MVP metrics you're looking to drive with a notification system, and to understand which notification channels will be most relevant for your internal and external customers.

While you’re at it, why not check out Courier?

Courier provides a comprehensive, easy-to-integrate API that takes care of all notification types. Start with an MVP, and add more functionality later without locking yourself into a particular provider.

How to Add a Notification System to your MVP

Related Posts