3 ms·

Hey HN, founder here. I’ve been working on Flute for just over a year now. I got this idea after being utterly fed up with deliverability problems and lack of e

Hey HN, founder here. I’ve been working on Flute for just over a year now. I got this idea after being utterly fed up with deliverability problems and lack of easily searchable logs on Mailgun, SendGrid, Amazon SES, etc…which one do you use? However, these established providers have been doing email for almost a decade, so I can’t hope to beat them at the delivery game. SMTP/delivery magic is an ancient protocol with so many pitfalls and unwritten rules - it left me aghast. So instead of trying to build another SMTP relay, I tried to solve the problem by decoupling your email API from from the underlying servers and providers. I call these decoupled APIs "flutes": think of the air blowing in as your firehose of API requests, and the fingers of the flutist routing your email harmoniously through different servers. I propose these "virtual flutes" as a better way to manage transactional email in a load-balanced, provider-agnostic, failover-native, hot-swappable, exportable-logs fashion with full-text Elasticsearch for your data. The primary goal of Flute Mail is better deliverability - our secret sauce is making it easier to do proper segmentation and have more control over your email routing. "Configurable routing" means your API can be configured to route your emails through a different provider or FROM address on-the-fly (or even load-balance them to save money by using multiple free-tier offerings). I’m super conscious about reliability, so Flute was designed from the ground up to handle all sorts of failure modes [1], from MTA spam bounces [2], mistaken IP/domain blocks, server downtime, queuing delays, and other sporadic problems that happen surprisingly often with email delivery APIs. I call this configurable multi-provider setup "Smart Failover". Another unique feature of Flute is that we aggregate your email history and delivery metadata in an Elasticsearch cluster for fast analysis and easy customer service followups. If you’re concerned about a third-party storing your data, we offer the ability to interface directly with your own Elasticsearch cluster, keeping the data off our servers. Email data can be highly sensitive, so I believe it should be kept on servers you control. The business model I’m experimenting with is to offer all of these features for free to developers and small teams, because I know what a pain it can be to choose a good email API. I plan to monetize this service by charging bigger volume users. Please let me know what you think! [1] https://status.sparkpost.com/incidents/ldv2gdc96hx5 https://status.sparkpost.com/incidents/ldv2gdc96hx5 [2] https://mailchannels.zendesk.com/hc/en-us/articles/202191674-Fixing-the-550-5-7-1-RBL-Sender-blocked-IP-or-domain-error https://mailchannels.zendesk.com/hc/en-us/articles/202191674...

jabart 8y ago
Oh this is interesting. Do you all support sub-accounts or an agency model to handle multiple domains for separate clients?
- igammarays 8y ago
  Yes, “virtual flutes” are basically sub-accounts, designed for multi-domain, multi tenancy usecases. Though I'd be happy to talk more about your specific needs.
notheguyouthink 8y ago
Disclaimer: I don't know the emails. I am immensely curious how you're achieving better delivery rates - I'm browsing through the site now trying to understand this. I say this because at the end of the day, I thought any failures reflected poorly on the provider (SendGrid/etc) which puts the provider and the customer at a sort of war. > The business model I’m experimenting with is to offer all of these features for free to developers and small teams, because I know what a pain it can be to choose a good email API. I plan to monetize this service by charging bigger volume users. These plans scare me, fwiw. I appreciate trying to offer an affordable service to small teams where money is tight, but to small businesses like mine, our needs are often too big for the small tiers but too small to get value out of the next bigger plans. Many online services are expensive for us, despite us having revenue. Our margins our thin, I guess. This isn't a critique, I'm just trying to I guess advocate for a pricing model that fairly distributes the pricing load. Since we _(my company)_ always seem to get caught in the middle. Appreciate your work here, and I hope I find better understanding to eventually use the product!
- igammarays 8y ago
  It's not as adversarial as it seems. I should clarify, we achieve better deliverability through a combination of 3 techniques: 1. Making it easier to properly segment different kinds of emails (this is the #1 tip you'll find on all authoritative sources about email performance, including GMail's official guidelines for bulk senders) 2. Allowing you to dynamically adjust FROM's and sender IP's to isolate domain/reputation issues. 3. Catching provider failures, and retrying (Smart Failover). Only #3 reflects badly on the provider, "putting them at war" as you say. But the majority of our deliverability benefits actually come from the first 2 techniques, which is not really fighting with the provider, just using better tools on top of them. And thanks for the feedback about pricing. To be honest, my current pricing is a shot in the dark. We're going to have to figure out a better model as we go. Do you have any specific suggestions? Perhaps tying pricing to number of contacts/users instead of sheer volume?

jabart 8y ago

Oh this is interesting. Do you all support sub-accounts or an agency model to handle multiple domains for separate clients?

igammarays 8y ago
Yes, “virtual flutes” are basically sub-accounts, designed for multi-domain, multi tenancy usecases. Though I'd be happy to talk more about your specific needs.

notheguyouthink 8y ago

Disclaimer: I don't know the emails. I am immensely curious how you're achieving better delivery rates - I'm browsing through the site now trying to understand this. I say this because at the end of the day, I thought any failures reflected poorly on the provider (SendGrid/etc) which puts the provider and the customer at a sort of war. > The business model I’m experimenting with is to offer all of these features for free to developers and small teams, because I know what a pain it can be to choose a good email API. I plan to monetize this service by charging bigger volume users. These plans scare me, fwiw. I appreciate trying to offer an affordable service to small teams where money is tight, but to small businesses like mine, our needs are often too big for the small tiers but too small to get value out of the next bigger plans. Many online services are expensive for us, despite us having revenue. Our margins our thin, I guess. This isn't a critique, I'm just trying to I guess advocate for a pricing model that fairly distributes the pricing load. Since we _(my company)_ always seem to get caught in the middle. Appreciate your work here, and I hope I find better understanding to eventually use the product!

igammarays 8y ago
It's not as adversarial as it seems. I should clarify, we achieve better deliverability through a combination of 3 techniques: 1. Making it easier to properly segment different kinds of emails (this is the #1 tip you'll find on all authoritative sources about email performance, including GMail's official guidelines for bulk senders) 2. Allowing you to dynamically adjust FROM's and sender IP's to isolate domain/reputation issues. 3. Catching provider failures, and retrying (Smart Failover). Only #3 reflects badly on the provider, "putting them at war" as you say. But the majority of our deliverability benefits actually come from the first 2 techniques, which is not really fighting with the provider, just using better tools on top of them. And thanks for the feedback about pricing. To be honest, my current pricing is a shot in the dark. We're going to have to figure out a better model as we go. Do you have any specific suggestions? Perhaps tying pricing to number of contacts/users instead of sheer volume?