Banger brings automated Journeys, campaigns, product emails, mailboxes, and customer replies into one platform your AI can operate. Turn signups into active users, recover abandoned carts, and bring customers back. Your AI builds branded workflows, tests and translates emails, and answers replies from the same chat. Review and edit everything in the web app. Run it from ChatGPT, Claude, or other AI apps. Start free with 100 emails a day, unlimited contacts, and unlimited mailboxes.
Hey Product Hunt 👋 I'm Tiago.
I’ve spent the last few years building chat apps, first at Beeper, including Beeper Mini, and then at Automattic. Most of my work has been deep app engineering: native clients, messaging surfaces, sync, reliability.
One thing I kept running into is that email still feels built for one person, even though a lot of company work happens there. Support, sales, invoices, recruiting, partnerships. It all lands in the inbox, but teams still end up sharing passwords, forwarding threads around, or pasting drafts into Slack when they want someone else to review a reply.
So I left my job and started MuchBetterApps with a friend who has spent years building and operating infrastructure. Banger is the first thing we’re building.
The basic idea is shared email with review built in. You can have shared mailboxes, real permissions instead of one shared login, and a way to put an email up for review before it sends. That can be for a teammate’s draft, or for something an AI agent wrote. The closest analogy is probably a pull request, but for email.
One important detail: for custom domains, we are not just putting a nicer UI on top of someone else’s email product. We built our own mail infrastructure for receiving and sending email, including the domain setup layer. We are not relying on AWS SES, SendGrid, Postmark, Mailgun, or another hosted email service for that part. There is a lot of unglamorous work in deliverability, routing, queues, DNS setup, bounces, retries, and abuse prevention, but I think owning this layer matters if we want to build the kind of email product we have in mind.
Today we're launching the native Mac app. It supports your own domains and Google Workspace. For new domains, we’re trying to make setup less annoying. For existing Google Workspace teams, the goal is to add the collaboration layer that Gmail does not really have.
This is early access, so it’s not the whole vision yet. There are 500 open spots now and we plan to open more as the infrastructure scales.
I’ll be around in the comments. I’d love to hear what you like, what feels unclear, and what you think we’re missing. Thanks for checking it out.
The "pull request for email" framing is exactly right. I build support and sales agents for ecommerce stores, and
review-before-send is the single thing that makes owners comfortable letting an agent anywhere near their inbox. So, it
is great to see it treated as a first-class feature instead of a bolt-on.
The question that I think decides whether this scales: what happens after a reviewer has approved 50 routine drafts in
a row and starts rubber-stamping? Do you plan per-agent or per-thread-type trust levels (auto-send the routine stuff,
always hold refunds, pricing, anything with money), or sampled review once an agent earns confidence? That dial
between safety and approval fatigue is the hardest part of this pattern in my experience.
Also, respect for owning the mail infrastructure yourselves. Deliverability, bounces and abuse handling are unglamorous, but that layer is usually where products like this live or die.
Congrats on the launch, Tiago.
@syed_noor4 Hi Syed, ty for checking it out. When you add a human and teammate right now you can choose the permission level. I think we're well positioned to experiment with per-agent or per-thread type trust levels, similar on how code harnesses have the 'only ask for actions as detected as potentially unsafe'. We'll explore this idea on the second half of the year. Thank you for suggesting the per-thread-type trust level, I haven't received this feedback yet.
@tgloureiro The code-harness comparison is a good one, with one difference worth keeping when you build it: a bad code action is usually reversible, a sent email is not. So "detected as potentially unsafe" works better as explicit categories (money, refunds, commitments, anything legal) than model confidence alone — confidence is exactly what fails when the model is confidently wrong. Excited to see where you take it in H2, and glad the per-thread idea was useful.
Building your own send/receive infrastructure instead of layering on SES or Postmark is the choice most teams talk themselves out of because the ROI takes years to show. But it's the one that separates products that stay flexible from ones that hit ceilings the moment their upstream provider decides to change something.
The "pull request for email" analogy is the tightest way to state that pattern I've heard. Review-before-send with AI drafts is exactly the missing layer, I've watched teams try to bolt this on with Slack channels, forwarded threads, and shared Google Docs, and it collapses within a month because the review context doesn't survive being ripped out of email.
Genuine question, for someone running cold email operations across multiple mailboxes and warmed domains, does Banger's shared inbox model extend to that use case, or is it strictly for shared team inboxes like support@ and sales@? The reason I ask: cold email is one of the places where "one draft, three eyes on it before it goes" would materially reduce misfires, but the current tooling assumes single-operator workflows.
@elias_motionfy hey Elias, yes, you can share any mailbox, even gmail accounts with other teammates to do cold email and everything.
@tgloureiro Good to know, was hoping the answer was yes. I'll keep an eye on where Banger goes since the review layer is exactly the piece missing from every cold email tool I've used, including the one I'm currently running my own ops on.
Curious about one thing since you mentioned Gmail accounts specifically, do the review permissions work the same for domains you own outright versus Gmail Workspace domains, or does Gmail's OAuth scope limit what you can do on that side? Asking because half my mailboxes are on custom domains with SMTP/IMAP and half would be Google Workspace if I moved, and I'd hate to have that split experience.
How do you envision the AI agents handling email threads with multiple stakeholders or complex customer support issues?
@aymnart
1- We are going to enable you to use external agents, on which you shared the proper context and gave proper tools and skills to answer very complex issues.
2- The main Idea on Banger is that teammates or AI agents can make reviews without sending, i.e. they can suggest something and rely on an advanced opperator to approve sending as well.
How do the AI agents actually decide when to draft a reply vs just label something, and can I set per-agent rules or do they all run on the same defaults?
@naime162129
Hi Naime, emails are always labelled by AI (being cloud or local AI).
Regarding processing of the queue:
When you create an internal agent, you can setup the per-agent rules and the send capabilities (draft and ask for review or can send). On your workspace you can have as many different agents as you want to deal with different needs.
On this early preview, you still need to assign the email to one of the agent so it does draft or send it depending on its permissions. We have auto-triage on the roadmap, on which you will define rules so the email/task is given automatically to one of the agents or a human.
how does the AI scoping actually work in practice, like can two agents see different drafts of the same thread or is everything shared across the team
@melihlidiphxj hey Melih, you can choose who access which mailbox(human or agent) and send permissions for each one.
Scoped access + human review before send is the right trust boundary for mixing AI agents into shared inboxes. How granular does the scoping get - can one agent draft-only on support@ while another gets broader access on sales@, or is it set per-mailbox rather than per-agent?
@dannyheng hey Danny, yeah same for teammates and AI agents: you can choose which mailboxes they have access. For example, you can have a support agent answer on @support and @help and a sales agent answering only on @sales. Same as teammates, you can invite some people to some of the mailboxes only.