A single API for multi-channel user notifications.
Batch: 2019 Summer
Status: Successful


A single API for multi-channel user notifications.
Batch: 2019 Summer
Status: Successful


A single API for multi-channel user notifications.

Courier makes it easy to add multiple channels for user notifications. Think of how Slack or Twitch intelligently route notifications to the right medium - if you're active in your browser it shows it via browser push, if you're idle it'll send it to mobile push, or it can always fall back on email. Courier also makes it easy to add emerging notification channels like notifying users within their own Slack organization, via your instance of Intercom, or over a messaging channel like WhatsApp. Finally Courier can further reduce engineering costs by delivering out-of-the-box UI kits for managing notification preferences and subscribing to content.


Over a two year period my team and I rebuilt the legacy experience of Eloqua by adding a new REST API atop the legacy .NET codebase and building one of the first enterprise Single Page Applications to power our new UI/UX in 2010. We leveraged our new UX to win deals we were previously losing to Marketo, took the company through an IPO, and ultimately sold it to Oracle where it is now the Oracle Marketing Cloud.


At Winmore we developed a collaboration feature for users to work together using tools like real-time chat on RFPs they are pursuing. We struggled to make user notifications as smooth of an experience as what we were used to out of our preferred tools, e.g. Slack. As head of both engineering and product I searched for a solution to this but all existing solutions are either too limited (only a couple of channels) or too focused on the marketing use-case instead of product/engineering usage.

Most companies that support multi-channel notifications have to build that support internally. Twitch just launched their "Smart Notifications", built by an internal engineering team. Existing multi-channel offerings (Amazon Pinpoint, Twilio Notify, etc.) usually only support a couple of channels - and they only support themselves as providers for those channels. Courier is agnostic to the underlying provider, similar to Segment, Zapier, etc.

Competitors line up in two categories: marketing focused, such as Iterable (, and engineer focused, such as Twilio Notify. Iterable is easily the most robust competitor in this space, but is focused on a different buyer persona and thus a different set of features. With the acquisition of SendGrid, I expect Twilio to re-invest in this space in the future - currently Twilio Notify is not a compelling product. I still expect whatever solution Twilio brings to market to be Twilio+SendGrid-centric rather than open to many providers, but given their dominance in both of those respective channels, they're certainly who I fear the most.

The applicability of the Segment or Stripe playbooks of locking in new startups while they're young and looking for an easy implementation-path and then scaling revenue commensurately as their revenue grows is huge, and is different from the martech playbook competitors like Iterable are running. This playbook requires targeting engineers looking for fast solutions to common early problems as well as features that let you scale pricing and penetration within those customers as they themselves grow.

Courier has three paid pricing plans that discriminate based upon the number of notifications sent per month. This maps to how incumbent single-channel notification providers charge and I expect Courier to be able to charge prices comparable to a single-channel provider. The customer will be paying for both Courier and the underlying providers so it may result in Courier only being able to charge some fraction of a comparable single-channel provider.

There are at least two existing individual channels that support $100M+ ARR (and in some cases much, much more) and two more supporting $10M+ ARR in revenue for the leader(s) in that space: email (SendGrid), SMS (Twilio), mobile push (Amazon SNS, OneSignal, Urban Airship), browser push (Pusher). Achieving revenues in excess of $100M ARR is achievable.


A more abstract version of Courier that I have considered is an OEM integrations provider. Think: embeddable Zapier or IFTTT. B2B applications often need to let their users enable integrations between their service and other services, but this is built by hand today. Tools like Zapier or IFTTT are currently focused on enabling the end-user, but not on letting a SaaS provider easily offer certain out-of-the-box integrations.

When I incorporated Courier via Stripe Atlas in January, it was the middle of the government shutdown. Atlas uses Rocket Lawyer to file the necessary paperwork, including for your EIN. After some time it became clear that my EIN was taking longer than anticipated to arrive so I checked in with the folks at Stripe, who then checked in with Rocket Lawyer - turns out any 3rd-party agent registering an EIN on behalf of someone else must do so with the IRS via fax. With the government shutdown the fax lines were also down; I suppose there was simply nobody there to pick up whatever papers were arriving at the fax machine!

Rather than wait through what was expected to be at least a multi-week delay after the government opened back up, I instead used the IRS website to apply for my EIN. It was free, took roughly 30 seconds, and the EIN document was emailed to me within a minute or two…


Get notified
When there are
Inline Feedbacks
View all comments