Transactional email, and the support that comes back.

Every business app sends email: order confirmations, receipts, password resets, notifications. Those emails go out from a no-reply address, and when a customer hits reply, the answer disappears into nothing.

SimpleFlare does both halves. We send your transactional email, and the replies land in a shared inbox your team can actually answer from.

How it works

1
You connect a domainAdd your sending domain and we walk you through SPF, DKIM and DMARC. Nothing sends until the domain is verified and authenticated.
2
Your app sends through usCall the API, or build the email from a template with live preview. Opens, clicks, bounces and complaints are tracked per message, and suppression is automatic.
3
Replies come back to a real inboxWhen someone replies, it becomes a conversation in a shared inbox with assignment, notes, saved replies and search. Not a support ticket in a different product with a different bill.

Why both halves belong together

The two things are usually sold separately. Transactional email providers deliver well but give you nowhere for the reply to land. Support desks are built around conversations and have no way to send your app's email in the first place. So small teams buy both, wire them together, and pay two bills for one conversation.

For a large company that split is fine, because the developer and the support lead are different people with different budgets. For a small business they are usually the same person, and the split is just friction.

What we charge for

One flat price per month that includes a block of outbound sends, your seats and your businesses. Answering a customer is always free, because a reply costs us nothing to deliver. If you go past your included block you pay a published per-1,000 rate rather than being pushed onto a bigger plan, and we email you at 80% and again at 100% so it never arrives as a surprise.

Hiring someone should not increase your bill. Seats come in blocks rather than per agent.

What we deliberately do not do

We are a transactional sender. That is a choice, not a gap we plan to fill.

No bulk blasts, no purchased lists, no drip funnels.

Our Acceptable Use Policy prohibits purchased, scraped or non-consented lists and unsolicited bulk email. Staying transactional is what keeps deliverability high for everyone sending through us. If you need mass marketing, we are happily the wrong choice.

How it is built

SimpleFlare runs on Cloudflare's network: outbound goes through Cloudflare Email Sending, inbound arrives through Cloudflare Email Routing and a Worker that hands it straight to your inbox, and attachments live in R2. Fewer moving parts between your app and the person reading the email.

Who builds this

I am Slavi. I build and run SimpleFlare myself.

Before it was a product it was my own infrastructure. I run a handful of small software products, and every one of them had the same two problems: it needed to send transactional email properly, and it needed somewhere for the replies to land. I was either paying for two services per project, or sending from a no-reply address and quietly losing whatever customers wrote back.

So I built one thing that did both, and moved my own products onto it. SimpleFlare still handles their email today. It is the same inbox I open every morning, which is where most of the small decisions come from: the undo when you close the wrong conversation, replies that keep the sender's formatting instead of flattening it, the warning at 80% of your send block rather than a surprise invoice. Those exist because I got them wrong on my own customers first.

If you write to [email protected], it lands in that inbox and I am the one who answers. You can also find me on X.