Launch HN: MagicBell (YC W21) – embedded notification system for your product
Building a notification system is challenging. We built robust email notifications at my last startup SupportBee [0], and it took us weeks to nail down the threading, reply by email, unsubscription links, and notification preference management. When we wanted to add an in-app inbox, I felt that we were building a mini email client into our app. A well designed in-app experience needs real-time updates and state management (read/unread/archived) apart from a lot of UI polish.
Not only do we save you months of work to begin with, but we also have an extensive product roadmap with features like email templates and grouping of notifications. Your customers will get a better experience each day without you having to invest in the development effort. Apart from customer-facing features, we plan to add a debug interface and analytics so you can get more visibility into your notifications.
Our embeddable notification inbox is written using React and MobX, and we use Ably.io for real-time updates. We offer a React SDK [1] that lets you build a custom interface, and we use Storybooks to test our UI. Fun fact: you can see the entire catalog of React components we offer [2]. We extracted the network layer of our embeddable into a Javascript package so customers not using React can use that to build a custom interface [3]. We'll work on Vue & React-Native SDK next. Our backend is hosted on AWS.
Thank you for reading. Please try out our product and send us your feedback, questions, and ideas. If you have built a notification system at work, we’d love to hear about your experience!
[0] https://www.indiehackers.com/post/ama-i-am-a-transgender-ent... [1] https://www.npmjs.com/package/@magicbell/magicbell-react [2] https://magicbell-react.netlify.app/?path=/story/magicbell-i... [3] https://www.npmjs.com/package/@magicbell/core
59 comments
[ 4.2 ms ] story [ 127 ms ] threadWhat sets you apart?
This product makes so, so much sense. I can recall at least 3 times over the past few years when I've had to build some version of this for my projects and would have loved to use MagicBell.
If you're able to share, where have you found initial growth? Has it been on the early stage startup side / enterprise?
Also, small typo on the pricing page "engineerrs" in the Business tier.
All the best
We see traction with early and later-stage companies, but the bigger orgs take their time to launch since they usually need buy-ins from at least a few people - developers, designers, and product managers. We got some interest from big enterprises, but I need to get better at working with them over the long-drawn process!
Courier (https://www.courier.com) is also in this space, but we're focused on other channels like email, Slack, SMS, MS Teams, SMS, etc. as well as handling orchestration capabilities around lists, preferences, and sequences. I'm pretty confident you & I started Magicbell & Courier for the same reason: we were both tired of seeing this have to be built over and over.
Glad to see the space is heating up!
I am super impressed by your execution and hope to catch up in person once this pandemic is over. It is indeed great to see good solution in this space :)
We are just thinking about adding in-app notifications so will have to check out MagicBell. Looks cool. Congrats on launch.
Congratulations on the launch. Love this idea and execution. I have spent too much of my developer life building notification systems. It's a no-brainer to use this.
There are a couple of reasons to price based on the MAU. Unlike services like Sendgrid that route an email and then forget about it, we have to maintain a persistent connection for every active user (while they are in your app) and support an API to fetch and show them their notifications. Second, a lot of people don't know their notification volume. But like I said, definitely listening to all the feedback and open to figuring out better pricing models.
The other thing would be, that the react package could export not only hooks to interact (useMagicBellEvent), but also provide some hooks or headless components to easier integrate with existing UIs. Something like this is very important to all external services we bring in, because our Product Design should feel like one.
1. We are going to remove Mobx. It will also reduce the learning curve for our customers. This change won't affect our API and will be fully backward compatible. We are considering Valtio as an alternative [0]. 2. As much as we can help it, we are not going to embed iframes. We'd love to deliver a native, and lean experience. 3. We already provide a network layer library [1] and want to offer more headless components. Can you give us some feedback on what you'd like to see? We are very inspired by Downshift's approach [2].
[0] https://github.com/pmndrs/valtio [1] https://www.npmjs.com/package/@magicbell/core [2] https://github.com/downshift-js/downshift
Whether this is useful will depend on how flexible the system is. Is it possible to define categories of notifications with different behaviors? Can you customize the UI to fit in seamlessly with your app? When notifications get sent by email, can you send them in batches so the users don't get inundated in task assignments etc?
We don't batch emails yet, but we will work on that in the coming months—also, an ability to send digests. The unique thing about our approach (or vision, if I may) is that we want the user to decide how they want to be notified and as an app developer, you shouldn't have to think about it at all.
You can add a category to every notification you send to us, and you can also set up notification preferences for the user based on the category and the channel. In the coming month, you'll be able to add templates based on category and selectively disable channels for some categories. Happy to keep you posted on the development of the product if you leave your email in Intercom. Thanks!
Looking forward to finding other cool ways to work together.
Edit: Docs are updated and change is deploying now. Thanks for the heads up Hana!
Sometimes they come late, get duplicated or even not arrive at all, i'm excited that there are more startups and companies providing this service.
There are companies out there that provide time critical notification updates, courier systems, parcel tracking, financial services, stock trading, emergency services, cryptocurrency movements, etc that would benefit from this.
I would love to see if there are more startups or products out there like MagicBell that have well designed notification systems that guarantee notification delivery without error.
Kudos on the release!
We don't currently do in-app notifications so not directly like MagicBell, but handle a lot of the other challenges you mentioned. We were heavily inspired by how Slack solves this problem (they're one of our investors):
https://www.courier.com/
You're obviously doing great work in your own right and we'd be happy to help you out on your own thread, but what you're doing in this one is just not very nice. If someone else did that to you, we'd tell them to stop as well.
We detached this subthread from https://news.ycombinator.com/item?id=26040402.
The other (and better way) is to initialize the embed with an HMAC generated on your backend using the API Secret. You can do this with both email and external_id - https://developer.magicbell.io/docs/turn-on-hmac-authenticat....
I wanted to pile on a little bit here and say this paragraph isn't really comforting to me:
> While unlikely to happen, it is possible for a savvy user to open their browser's developer console, obtain your MagicBell project's API key from your website's source, initialize the widget on their own website with your API key but with a different user's email (if its feasible for them to guess one) and start viewing notifications of that user.
I suspect this was done for developer experience reasons? You seem to know it's not secure to pass in an email directly, especially if anything sensitive is coming across in notifications.
For me at least, allowing the non-HMAC configuration makes me wonder what other security corners have been cut. I'd rather that option didn't exist and the company took a more security-forward stance.
Regardless, the copy on the website is improved. You may also want to add a warning and link anywhere your website documents the "userEmail" option.
On another note, in terms of the implementation here, I'm surprised you're asking users to use HMAC and base64 manually, instead of using standardized JWTs. Did anything in particular motivate that decision?
I quite like the product overall - I think it's very clever how you componentized everything. The security decisions just have me concerned.
Be asured that we take security very seriously. We are in conversations with banking platforms, and with that in view, we are planning to get a SOC 2 certification very soon.
I like the idea of bringing subsystems into fully separated products. First comment boxes and now notifications.
Believe it or not, I was drafting this exact idea this in my notes for the last couple of weeks, haha.
But then I was confused when I saw React.
I'm not sure why you would have developed this in a UI framework like react instead of something more generic and embeddable like vanilla js, or web components?
We built a react library for our current customers, and we are planning wrappers for other UI frameworks, too. The core of the MagicBell client, though, is completely decoupled from React.
We also offer a UMD bundle you can embed without having to worry about React at all, and a ESM bundle. Our customers were able to embed it in products with very different stacks.
Sign up and try it! We'll be very happy to help you integrate MagicBell into your product.
Can you sign a BAA?