https://www.youtube.com/watch?v=EeL-GcGmN7E&feature=youtu.be

In-app notification center for web & mobile apps

MagicBell is an out of the box, notification system with multi-channel delivery. Notifications are created via the API and the embeddable notification center can be fully customized to match your product's UI and UX. Companies with existing email notifications can simply bcc them to a project-specific email address to roll out MagicBell to their users within 30 mins. You can think of it like a smart router for your company’s notifications to your customers.

MagicBell enables you to think in terms of users and respect their notification preferences, instead of being bogged down by the complexity of understanding platform APIs for different channels.

Barcelona. After YC, I’ll continue operating from Barcelona. The business is a Delaware C-corp.

We have a stable MVP delivering over a million notifications a month for two B2B apps. Here is what's already deployed:

* The core APIs (notifications/preference management)
* Javascript based In-app notification center with real-time updates
* Email source and delivery channel
* Open-source libraries for React (to build custom interfaces) and Ruby (for creating notifications and managing user preferences in Ruby/Rails apps).

In terms of traction, we are signing up one enterprise lead a week through content on our blog.

About six months, of which the last month has been full time.

* MagicBell is powering notifications for SupportBee, my previous company with over 500 enterprise customers and 20,000 enterprise users.
* We are live on another B2B product in the SaaS collaboration space. They are using the free tier.
* We are currently onboarding a series-A funded insurance marketplace in Europe. They have signed a contract to bill them at $299/mo once they go live in October.

The august revenue is committed but not yet realized since we are still waiting for our EIN to set up our bank account and Stripe. We hope to have it all in place by the time YC sends out the interview invites.

I am working on MagicBell because it's a problem faced universally by B2B apps, and one I have experienced personally at my last company - SupportBee, a shared inbox product.

There, we deliver over a million notifications a month to our users. Before MagicBell, we spent a significant amount of time writing code to figure out whom to notify (based on the activity and their preferences), delivering the notification via email, and providing customer support when it wasn't delivered timely. When our users asked for an in-app notification center and mobile push notifications, we realized that we'd have to do a lot more work, especially if we wanted to avoid duplicates across channels. We talked to other companies at our scale and validated that they struggle with this problem too.

Instead of solving this problem just for SupportBee, we decided to build MagicBell.

Currently, the only substitute is building the notification system in-house. Based on our experiences, and user interviews, it takes a team of two engineers (frontend+backend) and a designer a minimum of two months to build a basic real-time notification center with multi-channel delivery. The team needs to understand and use APIs from Twilio and Pusher, etc. Usage analytics, debugging logs, fine-tuning the UX, or performing any day-to-day maintenance and troubleshooting is even more work.

Twilio provides APIs for delivering notifications on different channels and hence could be considered indirect competition. In fact, Twilio just participated in the Series A funding of XXX, that’s solving the same problem, albeit with a different approach.

It's possible that companies like Pusher or Onesignal offer a competing product in the future.

In an ideal world, everyone would use our API from day one and skip building email notifications entirely. However, today, most companies have already invested in their email notifications and are reluctant to switch to a new API. We find that it's vital not to underestimate this inertia. To help them migrate to MagicBell, without writing any code to talk to our API, we let them bcc their existing email notifications to us and embed our notification center in their product. This setup takes less than 30 mins. Over time they can start using the API to build new notifications. This quick and low-risk way of delivering value to their users significantly reduces the friction of adoption.

We charge a subscription fee for MagicBell's APIs and UI components. The pricing depends on a combination of the number of channels, active user count, notifications volume, and data retention period. Given the business model and deep integration into our customers’ code-base, we expect low churn and healthy expansion revenue (150-200% YoY).

At an average revenue per account of $4k/mo and net revenue retention of 150%, we expect to make $30million/yr in the next five years or so, given the right growth capital. The first-mover advantage, combined with the growing market opportunity and our team's expertise in SaaS, makes this a realistic target.

Our blog post describing the challenge of building a complete notification brings us one lead a week. Given the search volume for relevant keywords, we plan to publish more valuable content to double down on organic user acquisition.

Additionally, we are implementing several channels to generate growth - cold emails to targeted companies, a freemium model with a MagicBell branded widgets and partnership with providers of channel APIs (email/text/push). We hope to accelerate all these efforts with the additional funding from YC.

Hana (founder) is writing the code with Josue, core team member.

Restaurants and hotels spend an insane amount of money on electricity but obsess over keeping lights turned off in toilets. Who hasn’t found themselves in a dark toilet because the motion sensor flicked the lights off while you were doing your business? :)

While I have a great team, as a transgender female founder, I lack the industry network to make this business become the industry leader it can be. I can benefit tremendously from the advice, connections, and support that YC offers.

I have been building tech companies since 2007 and known about YC since then. In 2012, I applied with my last company (SupportBee) but didn’t make it in.