[HN Gopher] Launch HN: Courier (YC S19) - Developer infrastructu...
___________________________________________________________________
Launch HN: Courier (YC S19) - Developer infrastructure for product
notifications
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/
Author : troygoode
Score : 74 points
Date : 2022-03-02 14:36 UTC (8 hours ago)
(HTM) web link (www.courier.com)
(TXT) w3m dump (www.courier.com)
| johncole wrote:
| Nice work!
| troygoode wrote:
| Oh hey, I know you! Congrats on your new role John!
| kenrose wrote:
| 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. :)
| troygoode wrote:
| Hey I really appreciate it! I just saw the news about your
| Series A this morning btw - congratulations!
| esilverman wrote:
| incredible product and team
| troygoode wrote:
| Thanks Eric - we're big Netlify fans, too!
| cridenour wrote:
| 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.
| troygoode wrote:
| 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.
| adv0r wrote:
| change the plain password example maybe? It makes my eyes bleed
| troygoode wrote:
| That is a really good point. We should probably turn this into
| a 2FA code example instead.
|
| Edit: fixed!
| adv0r wrote:
| fantastic
| unamashana wrote:
| Congratulations on the launch! It's great to see more innovation
| in this space.
| troygoode wrote:
| Thanks Hana! I hope you and your team are doing well!
| dchuk wrote:
| 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?
| troygoode wrote:
| 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).
| dchuk wrote:
| Wonderful, good job and good luck!
| ajax33 wrote:
| 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?
| troygoode wrote:
| 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...
| jacinda wrote:
| Hi Troy! Was happy to see this on the front page this morning!
| troygoode wrote:
| Great to hear from you Jacinda! I hope you and Nick are doing
| well!
| mderazon wrote:
| 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"
| freeqaz wrote:
| 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
| [deleted]
| tejaskumthekar wrote:
| [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 :)
| freeqaz wrote:
| 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?
| troygoode wrote:
| > 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.
| tejaskumthekar wrote:
| 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]
| freeqaz wrote:
| 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.
| nicoburns wrote:
| 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.
| worldsoup wrote:
| 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.
| vincentmarle wrote:
| 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).
| troygoode wrote:
| 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).
| troygoode wrote:
| 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?
| [deleted]
| troygoode wrote:
| > 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.
| lambda_dn wrote:
| 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?)
| troygoode wrote:
| 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.
| lambda_dn wrote:
| 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.
| troygoode wrote:
| 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.
| lambda_dn wrote:
| 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.
| troygoode wrote:
| Are there any providers we don't have that would be
| helpful? We're always adding more.
| lambda_dn wrote:
| Sorry I see you have plenty, thought it said somewhere
| you only had 4-5.
| suhas_rd wrote:
| 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.
| :)
| lambda_dn wrote:
| 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.
| tejaskumthekar wrote:
| well the cost to build the architecture orchestration is
| where the real "value" is
___________________________________________________________________
(page generated 2022-03-02 23:01 UTC)