I'm an engineer and have been in engineering leadership for a long time. I kept seeing my teams spending hundreds or thousands of hours building notification infrastructure on top of messaging APIs to solve for common use cases, and it really just felt like a missing abstraction layer to me.
At one point we were building a chat feature for our product and just wanted the ability to let Bob @mention Alice and have it get intelligently pushed either in-app, via mobile push, or email—something Slack does well. As we dug into it we discovered how expensive it is to roll-your-own. Companies like Airbnb have dozens of engineers that work only on this part of their infrastructure! We realized it was going to take way more work than we could justify, so I went to Twilio, AWS, et al asking if I could buy a solution and learned that that just didn't exist. Somebody needed to create it.
Most product companies rebuild the same notification infrastructure on top of services like Twilio, Postmark, APNS/Firebase, etc. Those pipes are great, but there is significant complexity in scheduling notifications, templating, retrying, and so on. Courier gives developers higher-level abstractions that make it fast to develop robust notifications, and much cheaper to maintain moving forward.
Courier has been heavily inspired by a now-famous article by Slack’s engineering team about how they decide when (and how) to send a notification to a user using a complicated state-chart [0], as well as a post by LinkedIn’s engineering team on their own notification infrastructure [1]. We make all of that possible for teams and products of any size. Our YC pitch was "Segment for notifications."
Our customers plug in their existing messaging providers for the channels they want to notify customers on (e.g. Postmark or SendGrid for email, Twilio or MessageBird for SMS, etc.) They then call the Courier API which is able to correctly respect users' preferences, route a message to the “best” channel for a user, schedule messages to send seconds or months later, synchronize state across email and app inboxes, have a consistent template design experience for engineers and non-engineers on their team, ensure robust delivery at scale, and more.
A core focus for us from day one has been templating, something I think most developers have been frustrated by. We of course let you use your existing template code, but we also give you the ability to use our cross-channel JSON specification [2] or have both developers and non-technical teammates build templates for any channel using our drag and drop editor. In the latter cases, we use an abstract syntax tree under the hood to then render your message to the right format for each channel/provider combination – e.g. HTML for email and BlockKit for Slack.
Courier is free to sign up for and send up to 10,000 notifications each month – no credit card required. We offer usage-based pricing if you need to remove our “Powered by Courier” branding or send a higher volume of messages.
Our team’s mission is to make software-to-human communication delightful, for both developers and for the users they are notifying – so we’d love to hear your experience from either side. Have you had to build internal notification micro-services? Is there anything really cool you wish would’ve been easier, or wish you saw more products offering? Are there apps or services that you wish were more delightful today?
[0]: https://slack.engineering/reducing-slacks-memory-footprint/
[1]: https://engineering.linkedin.com/blog/2018/03/air-traffic-co...
by Andrey
Azimov