Why we built on Gmail instead of replacing it

Most shared-inbox tools ask you to move in. Point your MX records at them, retrain everyone on a new client, and hope the migration goes clean. We watched enough of those rollouts stall to make the opposite bet: leave the email exactly where it is, in Gmail, and build the collaboration layer on top.

Migration is where these projects die

The failure is rarely the software. It is the switch. Dispatchers have muscle memory in Gmail, deliverability is already tuned, and the entire company knows the address. Ask a fleet to cut over all of that on a Monday and you get weeks of half-in, half-out chaos where nobody trusts either system. Plenty of good tools never survive that week.

Transport versus source of truth

So we split the job. Gmail stays the transport: it sends and receives, it handles deliverability, it is the mailbox your team already uses. Mailex is the source of truth for everything Gmail cannot model, which is the collaboration: who owns a thread, what the internal note said, when the SLA clock started, which load this conversation is about.

Gmail is the wire. We are the workspace. Nobody has to move their email to get a shared queue.

Devon Reyes, Product

What that buys you

• No cutover. Connect the mailbox and the queue appears; nothing about sending changes.
• A safety net. If you ever leave, the email is right where it always was, in Gmail.
• Deliverability you already trust, because it is the same account brokers already reply to.

The tradeoff is that we have to stay faithful to Gmail rather than route around it, which is more engineering on our side and less disruption on yours. That is the deal we wanted. A shared inbox should be something you turn on, not something you migrate to.