Launch HN: Courier (YC S19) – Developer infrastructure for product notifications (courier.com)
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]: One thing I couldn't find at a glance is if you are consolidating webhooks from the providers to return deliverability status or clicks. That would definitely save a lot of boilerplate code in my projects. One interesting thing we do here is for channels like Slack & Teams that support webhook-based click interactions natively: we offer you a webhook proxy so clicking the "Approve" button on the Slack notification will hit Courier first (so we can count it as a "click") before proxying through to your approval handler. All of that data is then normalized in our logs, which you can view in our UI or have streamed to your systems via webhook. Demo example: https://reactinappnotification.com/
Docs: https://www.courier.com/docs/guides/providers/push/courier-p... Would Courier be a good fit for an Open Source product like what we're building[0]? Hey hey! yep I think Courier can totally be a good fit! Do you have a way to expose any plugin-like interface which can connect to external services? I'd be more than happy to contribute! Feel free to reach out anytime :) It's probably more useful for the cloud version of our product, thinking about it more. At least if we're using Courier primarily to notify leads/customers. In that case, would it make more sense to integrate Courier as a separate service or pipeline for managing engagement? Where is the line between something like MailChimp and Courier? Mailchimp has two services: a marketing tool for e.g. newsletters and a transaction email service (previously called Mandrill). Most customers use Courier alongside marketing tools like Mailchimp's newsletter tools - we're more for your active users, not marketing to potential users. We do integration with Mandrill / Mailchimp Transactional to add our orchestration, preference management, routing, templating, etc. tools so that you don't have to build those yourself on top of their pipes. ["a" can be any integration Courier supports - so it could be Twilio for SMS for instance]
["b" changes based on how you invoke the API - so you could do send just an email via Mailchimp, send just an SMS via Twilio OR both email and SMS OR SMS if email fails and so on --- this logic is configurable via both UI and API] I remember Troy explaining this when we spoke about picking the best "channel" to actually reach somebody, but I guess I forgot. Reading the docs, it was also ambiguous to me as to whether I would need to pay the fees from the providers on top of your fees. Sorry, forgot to answer this (but I answered in another comment): you "bring your own" providers so you'd indeed need to pay fees to that provider when applicable. We do offer lower per-message prices for high-volume customers and are even able to help customers with cost optimization in certain scenarios, e.g. dynamically routing SMS messages to the lowest cost provider depending on the recipient's region (e.g. MessageBird is 15% cheaper than Twilio in Germany). Does the cost per message include the cost to use the providers service (i.e. sendgrid?) We did a build vs. buy analysis and I'm so happy we went with Courier. It lets us manage user notifications in a single place across multiple channels. Good UX, easy to set up, and pricing is reasonable. 10/10. Would recommend. :) I wanted to know how this compares with customer.io in regards to the Segment integration. For example, can you build email campaigns based on multiple events / user traits? I.e. send an email to "all users who signed up 2 days ago and didn't complete onboarding" Leonardo DiCaprio sitting up in chair pointing at the tv screen I kid you not two days ago I said to my Jr. SRE "We need a way to bifurcate an alert to multiple channels via webhook" due to our unique observability needs and slaps knee here it is. We were about to launch off and try building something this quarter, and then here you come down off the mountain. Congrats on launching, looking forward to kicking some tires tomorrow morning. 1. It took a lot of time to build something robust enough that teams were willing to swap out their critical infrastructure for. There is a big different between your marketing automation system experiencing an issue vs. the system that sends out 2FA/magic link messages. 2. I really wanted to iterate on our API until it felt "HN worthy." That also took time. (For reference, Stripe did their HN launch a couple years post-YC for the same reason.) (And yes, YC definitely does bet on competitive companies in the same space!)60 comments
[ 498 ms ] story [ 2177 ms ] thread