[HN Gopher] Launch HN: MagicBell (YC W21) - embedded notificatio...
___________________________________________________________________
Launch HN: MagicBell (YC W21) - embedded notification system for
your product
Hey everyone! I am Hana, and along with my co-founder Josue, we are
excited to launch MagicBell (https://magicbell.io). You can embed
MagicBell in your web/mobile application to show users workflow
notifications in-app and real-time. If the user is not online when
you send them a notification, we can send them an email (or text).
For example, a project management app can use MagicBell to show new
tasks assigned to a user or tasks due soon. A code collaboration
app will notify users of pull-requests that need their review.
These notifications keep the workflow moving. 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
Author : unamashana
Score : 73 points
Date : 2021-02-05 15:56 UTC (7 hours ago)
| dzink wrote:
| Some thoughts: You are pricing per monthly active users, but
| there may be sites/apps that ping users all the time, and others
| that may do it far less frequently based on specific actions. It
| may help to break down pricing by number of notifications rather
| than active users.
| unamashana wrote:
| Thanks for the feedback. We keep track of all the feedback on
| the pricing.
|
| 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.
| raywu wrote:
| That's interesting. What's common from what you observe?
| Notification per user per month wise?
| unamashana wrote:
| In our early customers, there is is a wide range. As we get
| more customers we should have a better sense.
| troygoode wrote:
| Hey Hana - I love what you're doing with in-app. Congrats on YC!
|
| 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!
| nealjean wrote:
| we've been using courier since early last year and thank god
| because otherwise we would have spent 75% of the year building
| like 25% of courier so that we could email our users. one of
| the first products that I recommend to any software startup,
| insane how much time they will save you
| TommyDANGerous wrote:
| I built this for Airbnb and Courier is creating exactly what we
| had to have dozens of engineers building for us full-time over
| a span of 7 years. We are still building it and maintaining it
| today, but if Courier was around earlier in the days of Airbnb,
| we would've just used Courier instead of build it in-house and
| maintain it ourselves.
| adenta wrote:
| +1 for Courier! Big fan.
| keks0r wrote:
| Were also using Courier at laserfocus (https://laserfocus.io)
| for e-mail and it has been fantastic so far.
| collinpham wrote:
| +1. Using Courier at Stable (https://www.useStable.com) as well
| + it's saved us a ton of dev time!
| helena_merk wrote:
| +1 for courier! we at Glimpse (https://www.joinglimpse.com)
| needed a few new endpoints/features, and the team jumped on to
| help us launch quickly. great product and even better team
| behind it.
| lexiross wrote:
| +1, we are happy customers of Courier at LaunchDarkly!
| unamashana wrote:
| Thanks for dropping by Troy! Like you mentioned, we are very
| focused on the in-app piece as being the gateway to other
| features (notification preference, asking for permission to
| push). We believe that our customers shouldn't have to think
| about channels and how to orchestrate the notification flow.
| That's something MagicBell should figure out for them.
|
| 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 :)
| rwishnieedwards wrote:
| +1 for Courier!
| benjymessner wrote:
| We're just integrating with Courier now!
| schiavone wrote:
| Big fans of Courier. We use it at Calixa(https://calixa.io) to
| power our email and Slack notifications to customers. My eng
| team found it super easy to integrate.
|
| We are just thinking about adding in-app notifications so will
| have to check out MagicBell. Looks cool. Congrats on launch.
| [deleted]
| jeremynevans wrote:
| Great to see more startups in this space. Courier are awesome!
| And congrats to MagicBell, looking forward to trying it out
| mathewpregasen wrote:
| We use Courier ourselves and LOVE your product
| koopuluri wrote:
| Congrats on the launch Hana, Josue!
|
| 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
| unamashana wrote:
| Thanks for catching that typo. Pushing up a fix now.
|
| 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!
| hashamali wrote:
| Quick question regarding frontend integration. I see that you can
| embed a widget that requires an API key and the currently
| authenticated user's email. Does this mean that if I'm a
| malicious user, and I edited my local Javascript to swap the
| email with another user's email, I could view the other user's
| notifications?
| unamashana wrote:
| There are two ways to handle that. One is to use your external
| ID, if they are UUID or something random. That's security by
| obscurity.
|
| 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....
| thrwaway2020aug wrote:
| Hello! Great product and congrats on the launch!
|
| 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.
| unamashana wrote:
| I agree that this can be worded better and we will
| certainly do so. Thank you for your feedback. It's fairly
| common to see this pattern of HMAC off by default (ex:
| Intercom) to help people test their embed. Atleast at the
| moment we are in touch with everyone going live and make
| sure this is communicated to them (doing things that don't
| scale).
| unamashana wrote:
| Edited the doc to remove the bit about this scenario being
| unlikely. We take security very seriously and would be
| happy to get feedback on the new copy (or any other aspect
| of MagicBell).
| thrwaway2020aug wrote:
| I see your point with Intercom, but it feels like you're
| arguing that two wrongs make a right. It doesn't make me
| think MagicBell takes security very seriously, but
| perhaps I'm just paranoid.
|
| 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.
| loevborg wrote:
| Is this a NCaaS - a notification-center as a service? That sounds
| similar to offerings like Pusher, that help you build one of the
| most complex parts of your app.
|
| 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?
| unamashana wrote:
| We are similar to Pusher because we handle real-time updates
| for you. However, unlike Pusher, we offer UI components to
| craft a great user experience. You can use the packaged
| embeddable inbox or use smaller components to build something
| more custom. The UI is completely customizable to match your
| brand.
|
| 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!
| yannoninator wrote:
| This looks good, very glad to see MagicBell, push notification
| systems are extremely hard, just have a look at how Slack manages
| it and it's just the beginning.
|
| 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!
| troygoode wrote:
| > I would love to see if there are more startups or products out
| there like MagicBell
|
| 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/
| dang wrote:
| Would you please stop hijacking the other startup's launch
| thread? You've been all over this thread, changing the subject
| to yourself, and it's in poor taste. Worse, the comments
| underneath https://news.ycombinator.com/item?id=26038303 (which
| I collapsed for what should be obvious reasons) look blatantly
| gamed. I don't know how all those users showed up to talk about
| you, but if you did anything to make that happen, that's not
| cool.
|
| You're obviously doing great work in your own right and we'd be
| happy to help you out on our 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.
| troygoode wrote:
| Got it dang. Understood.
| dang wrote:
| Appreciated!
| [deleted]
| raywu wrote:
| Building notifications multiple times made me appreciate this,
| so, so much. Even larger companies have trouble with
| notification. One of my worst nightmares is notifications from
| Reddit and Airbnb (sorry TommyDANGerous). I hate it when email,
| in-app, push don't sync.
| keks0r wrote:
| Hey Hana & Josue, congrats on the launch. I like your approach of
| how to integrate it into products (via native React libs). I
| think you could go even a little bit further. One concern I would
| have is that by using your react library, I also bring in a new
| state management (mobx). In our case it would be fine, because we
| are using it already, for others it might be an issue. The most
| extreme version I found is from feedback.fish, which gives a
| native react component, but internally imports their scripts
| still in an iframe.
|
| 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.
| unamashana wrote:
| This is really good feedback.
|
| 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
| bvanvugt wrote:
| Hi Hana & Josue - congrats on the launch! This looks like a
| wonderful product. As a developer I've built (admittedly
| terrible) versions of this, over and over... look forward to
| trying it!
| troygoode wrote:
| Update! We love this idea here at Courier
| (https://www.courier.com/) and just launched a MagicBell
| integration (https://docs.courier.com/docs/magicbell) to make it
| easy to send notifications to email via
| SendGrid/SES/Mailgun/etc., SMS via Twilio/MessageBird/Plivo/etc.,
| mobile push, Slack, MS Teams, and - now - in-app!
|
| Looking forward to finding other cool ways to work together.
| unamashana wrote:
| Thanks Troy! Love the integration. Quick feedback: We also
| accept an external_id apart from email. This is the ID of the
| user in our customers' database. Can you please add support for
| that?
| troygoode wrote:
| Sorry we missed that! Will get it added ASAP.
|
| Edit: Docs are updated and change is deploying now. Thanks
| for the heads up Hana!
| ashastry wrote:
| Hi Hana & Josue!
|
| 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.
| hkh wrote:
| I can't tell you how many times we've had to rebuild this feature
| in the past! Super cool!
| tarun_anand wrote:
| Kudos for starting up.. These kind of features exist today in
| many martech systems. Full disclosure: I am the founder of one :
| www.appice.io but we are certainly not the first or only ones.
|
| What sets you apart?
| unamashana wrote:
| You are right that there are many marketing automation systems
| for sending emails or push notifications. We are focused on
| product notifications specific to a user's workflow. The API
| reflects that and, so does the design of the inbox. For
| example, the API accepts a category for each notification and
| you can set preferences per category (one of the categories can
| be marketing). When adding MagicBell to your frontend, you can
| write a custom click handler and redirect your user to the
| specific action they need to take on a notification. A lot of
| the marketing automation tools also lack an in-app inbox that
| offers a workflow for these notifications (read/unread/delete).
___________________________________________________________________
(page generated 2021-02-05 23:01 UTC)