unamashana

I probably didn't do a good job in listing down all the benefits. I skipped the biggest one - the YC network. It's an amazing network that's ready to adopt new products as well as invest in them.

YC also gives you a lot credibility. If you don't have a pedigree (previous exit, FAANG network), it's your buy-in in the big league.

Besides they invest 125k, which may not sound like a lot but is a good first cheque in that can get you pretty far on it's own.

Great article. Have you come across any studies that quantify the value of diversity and inclusion?

Congrats on the launch! I live with two cats and sadly I am allergic to cats. It's not super bad but certainly noticeable. Will your treatment work for people like me?

Thanks for pointing this out. We'll fix this shortly.

I must clarify that we use preact and not react.

Can you please elaborate on this point? What would you prefer instead?

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

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

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

In our early customers, there is is a wide range. As we get more customers we should have a better sense.

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?

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!

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

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.

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!

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

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