TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Launch HN: Courier (YC S19) – Developer infrastructure for product notifications

103 pointsby troygoodeabout 3 years ago
Hi HN! I’m Troy, the founder of Courier (<a href="https:&#x2F;&#x2F;www.courier.com" rel="nofollow">https:&#x2F;&#x2F;www.courier.com</a>). 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.<p>I&#x27;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.<p>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&#x27;t exist. Somebody needed to create it.<p>Most product companies rebuild the same notification infrastructure on top of services like Twilio, Postmark, APNS&#x2F;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.<p>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 &quot;Segment for notifications.&quot;<p>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&#x27; 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.<p>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&#x2F;provider combination – e.g. HTML for email and BlockKit for Slack.<p>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.<p>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?<p>[0]: <a href="https:&#x2F;&#x2F;slack.engineering&#x2F;reducing-slacks-memory-footprint&#x2F;" rel="nofollow">https:&#x2F;&#x2F;slack.engineering&#x2F;reducing-slacks-memory-footprint&#x2F;</a><p>[1]: <a href="https:&#x2F;&#x2F;engineering.linkedin.com&#x2F;blog&#x2F;2018&#x2F;03&#x2F;air-traffic-controller--member-first-notifications-at-linkedin" rel="nofollow">https:&#x2F;&#x2F;engineering.linkedin.com&#x2F;blog&#x2F;2018&#x2F;03&#x2F;air-traffic-co...</a><p>[2]: <a href="https:&#x2F;&#x2F;www.courier.com&#x2F;docs&#x2F;elemental&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.courier.com&#x2F;docs&#x2F;elemental&#x2F;</a>

18 comments

dvtrnabout 3 years ago
<a href="https:&#x2F;&#x2F;www.courier.com&#x2F;docs&#x2F;guides&#x2F;tutorials&#x2F;how-to-configure-multi-channel-routing&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.courier.com&#x2F;docs&#x2F;guides&#x2F;tutorials&#x2F;how-to-configu...</a><p><i>Leonardo DiCaprio sitting up in chair pointing at the tv screen</i><p>I kid you not two days ago I said to my Jr. SRE &quot;We need a way to bifurcate an alert to multiple channels via webhook&quot; due to our unique observability needs and <i>slaps knee</i> here it is. We were about to launch off and try building something this quarter, and then here you come down off the mountain.<p>Congrats on launching, looking forward to kicking some tires tomorrow morning.
评论 #30543866 未加载
ajax33about 3 years ago
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?
评论 #30528698 未加载
cridenourabout 3 years ago
Great idea and the site and API looks very well thought out.<p>One thing I couldn&#x27;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.
评论 #30528419 未加载
nicoburnsabout 3 years ago
This seems pretty useful, but pricing seems off: $0.005&#x2F;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&#x2F;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!<p>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.
评论 #30529735 未加载
评论 #30530169 未加载
评论 #30530141 未加载
评论 #30529184 未加载
评论 #30537484 未加载
okhobbabout 3 years ago
I am curious how this compares to an older YC company OneSignal. <a href="https:&#x2F;&#x2F;onesignal.com" rel="nofollow">https:&#x2F;&#x2F;onesignal.com</a> ... Sounds quite similar on the surface. Does YC bet on multiple companies in the same space?
评论 #30543862 未加载
kenroseabout 3 years ago
We use Courier at OpsLevel. It&#x27;s great.<p>We did a build vs. buy analysis and I&#x27;m so happy we went with Courier. It lets us manage user notifications in a single place across multiple channels.<p>Good UX, easy to set up, and pricing is reasonable. 10&#x2F;10. Would recommend. :)
评论 #30529386 未加载
lambda_dnabout 3 years ago
Looks very slick, also great domain name. I assume you&#x27;ll be adding more providers.<p>Does the cost per message include the cost to use the providers service (i.e. sendgrid?)
评论 #30529157 未加载
anandnairabout 3 years ago
Congratulations @troygoode. This is a real problem that needs to be solved. And this space is getting exciting. I&#x27;m working on something similar @ Engagespot(<a href="https:&#x2F;&#x2F;engagespot.co" rel="nofollow">https:&#x2F;&#x2F;engagespot.co</a>)
mderazonabout 3 years ago
Congratulations, this looks great.<p>I wanted to know how this compares with customer.io in regards to the Segment integration.<p>For example, can you build email campaigns based on multiple events &#x2F; user traits?<p>I.e. send an email to &quot;all users who signed up 2 days ago and didn&#x27;t complete onboarding&quot;
评论 #30543898 未加载
wizwit999about 3 years ago
Great launch. Just curious, did you guys pivot, interesting to see a launch 3 years later.
评论 #30543947 未加载
freeqazabout 3 years ago
I&#x27;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.<p>Would Courier be a good fit for an Open Source product like what we&#x27;re building[0]?<p>0: <a href="https:&#x2F;&#x2F;github.com&#x2F;lunasec-io&#x2F;lunasec" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lunasec-io&#x2F;lunasec</a>
评论 #30529096 未加载
评论 #30529060 未加载
chrisfrantzabout 3 years ago
Congrats Troy! You’re building a great platform, glad to see this on HN today.
评论 #30543909 未加载
esilvermanabout 3 years ago
incredible product and team
评论 #30529604 未加载
johncoleabout 3 years ago
Nice work!
评论 #30530215 未加载
dchukabout 3 years ago
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?
评论 #30527983 未加载
unamashanaabout 3 years ago
Congratulations on the launch! It&#x27;s great to see more innovation in this space.
评论 #30528430 未加载
adv0rabout 3 years ago
change the plain password example maybe? It makes my eyes bleed
评论 #30527876 未加载
jacindaabout 3 years ago
Hi Troy! Was happy to see this on the front page this morning!
评论 #30530125 未加载