Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Courier (YC S19) – Developer infrastructure for product notifications (courier.com)
103 points by troygoode on March 2, 2022 | hide | past | favorite | 58 comments
Hi HN! I’m Troy, the founder of Courier (https://www.courier.com). Courier replaces all the extra work developers have had to do to add different notification channels—email, browser, mobile, SMS, chat, etc.—to their product.

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...

[2]: https://www.courier.com/docs/elemental/




https://www.courier.com/docs/guides/tutorials/how-to-configu...

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.


I'd love to hear how it goes for you! troy@courier.com


Does this also support in-app notifications? If I wanted to show the last 20 notifications for each user inside my application, is there any API for getting those?


Yup! We support in-app notifications via real-time "toast" as well as an inbox where your users can see the last 20 (or more) notifications, mark them as read/unread, etc.

Demo example: https://reactinappnotification.com/ Docs: https://www.courier.com/docs/guides/providers/push/courier-p...


Great idea and the site and API looks very well thought out.

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.


Yes, we definitely consolidate (and normalize) state for deliverability, opens, and clicks across providers and channels.

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.


This seems pretty useful, but pricing seems off: $0.005/message works out at $5 for 1000 messages. Which is a lot considering half of these sending methods could otherwise be sent for free using a $5/month server, and it looks like. If we used this for push notifications, this pricing could easily exceed our entire monthly spend on infrastructure and SAAS tools!

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.


> ambiguous to me as to whether I would need to pay the 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.


At one of my jobs we were sending millions of notifications; our Twilio bill was $50-100K / month. At that level you start caring a lot about your cost per message and do everything you can to bring it down. Yeah it's always a hassle and annoying to implement a proper notification system, but the difference is that the extra effort is a one-time implementation cost, not an ongoing one (at least not an ongoing $50K/mo commitment at least).


FWIW we find that most software teams end up significantly rebuilding/refactoring their notification infra every 2-3 years, so it isn't completely a one-time implementation. Not to mention ongoing maintenance, supporting the product/design/marketing teams' change requests, etc.

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).


for most engineering teams the cost of building and maintaining a notification system goes well beyond a $5/month server, though of course it depends on use case and complexity. If you want the ability to render messages across multiple channels from a single template, unified logging across multiple channels, and flexible infrastructure that can scale with demand then you are already talking about a pretty expensive and complex system.


Totally hear you! We offer substantial volume discounts for high-volume senders to make sure we can fit within most teams' budgets. Do you mind if I ask how many messages you're typically sending?


I've sent 10s of thousands of notifications to people on discord which at that rate is hundreds of dollars for a free user. At that price a lot of use cases are eliminated.


10s of the thousands in the same month would indeed move you into our paid plan. If this was more like <10k per month for many months, you'd still be able to do that on our free plan.


I meant that if you were running something like Discord where you have users who over a year make $100s worth of notifications then that use case doesn't match the pricing model compared to a use case where you are dealing with a few users (where one @ doesn't refer to thousands of people)


Ooooh yeah, got it. We have lower per-message prices for customers sending at scale. We have our own hard costs to account for, but we work hard to make sure Courier can fit into most teams' budgets.


I am curious how this compares to an older YC company OneSignal. https://onesignal.com ... Sounds quite similar on the surface. Does YC bet on multiple companies in the same space?


George & the OneSignal team are great. We integrate with OneSignal (both their mobile push and email services). We integrate with more channels than using OneSignal directly (say you wanted to integrate with Slack or WhatsApp) and offer things like dynamic routing between channels & providers that OneSignal doesn't.

(And yes, YC definitely does bet on competitive companies in the same space!)


We use Courier at OpsLevel. It's great.

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. :)


Hey I really appreciate it! I just saw the news about your Series A this morning btw – congratulations!


Looks very slick, also great domain name. I assume you'll be adding more providers.

Does the cost per message include the cost to use the providers service (i.e. sendgrid?)


No, since we use your existing providers ("bring your own") you'd still have to pay for services that you plug in – just like Segment & analytics tools.


I see, so a customer would be paying you to use use their own providers? Not sure I see the value in that, but good luck.


Appreciate it! In the future if you find your engineering team is spending a lot of time building & maintaining this kind of infrastructure keep us in mind.


No worries, I get the idea and think it's a great execution of that. Im sure it is/will be a big success especially more so when you have a few more providers.


Are there any providers we don't have that would be helpful? We're always adding more.


Sorry I see you have plenty, thought it said somewhere you only had 4-5.


we have close to 40 providers and our list keeps growing every time either get a request from customer, (regardless they are paying or not) or when a new engineer joins our team. We are growing so by end of year will have to implement pagination for our providers page. :)


Yes I see that, incredible work done you guys have done. Just based on a surface level glance. Surprised this hadn't been done before (great ideas always seems obvious in hindsight), but you guys nailed it. Congrats.


well the cost to build the architecture orchestration is where the real "value" is


Congratulations @troygoode. This is a real problem that needs to be solved. And this space is getting exciting. I'm working on something similar @ Engagespot(https://engagespot.co)


Congratulations, this looks great.

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"


Customer.io is more focused on marketing automation (which your campaign use case sounds like) whereas we're focused on transactional notifications.

Next quarter we'll have some relevant new releases though, so stay tuned. :-)

https://updates.courier.com/board


Great launch. Just curious, did you guys pivot, interesting to see a launch 3 years later.


I was surprised nobody else pointed this out! No, no pivot. Two main reasons:

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.)


I'm also glad to see Courier doing well a few years after we first spoke about it. With our pivot to LunaSec since then, we might even be a future customer soon! Lots of webhooks in the future as we start needing to integrate with various services.

Would Courier be a good fit for an Open Source product like what we're building[0]?

0: https://github.com/lunasec-io/lunasec


[Disclaimer: I am an engineer at Courier]

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 :)


Thanks for the help. I'm just trying to think about how it'd work.

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?


Gotcha! I think easiest way would be a. You'd configure Mailchimp details (api key etc) inside Courier's provider/integrations interface b. Invoke Courier API and Courier would route it to Mailchimp

["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]


Ahhh, okay thank you for clarifying. The "stacked notifications", especially if something fails, makes total sense. That is what made it "click" in my head where Courier fits in the stack.

I remember Troy explaining this when we spoke about picking the best "channel" to actually reach somebody, but I guess I forgot.


> 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.


Congrats Troy! You’re building a great platform, glad to see this on HN today.


Thanks Chris! Hope things are going well at Loops!


Thanks Troy! All is well.


incredible product and team


Thanks Eric – we're big Netlify fans, too!


Nice work!


Oh hey, I know you! Congrats on your new role John!


This is a great product idea, but as a product targeting developers, having your first example payload show sending someone a password in plain text (which should never be done in any circumstance) is a real misfire. Why not change it to a password reset link?


Great point! I just changed it to a reset code (to make it a bit terser than a full URL just for the sake of brevity).


Wonderful, good job and good luck!


Congratulations on the launch! It's great to see more innovation in this space.


Thanks Hana! I hope you and your team are doing well!


change the plain password example maybe? It makes my eyes bleed


That is a really good point. We should probably turn this into a 2FA code example instead.

Edit: fixed!


fantastic


Hi Troy! Was happy to see this on the front page this morning!


Great to hear from you Jacinda! I hope you and Nick are doing well!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: