Why I stopped trusting full-access Gmail cleanup tools (and built my own)

3 September 2026 · Article 1 of 5 on how Mailwarden is built

My Gmail had drifted to 6,010 messages. Every cleanup tool I tried asked me for one of two things I wasn't willing to give: hours of reviewing emails one at a time, or full access to my mailbox and blind trust that nothing would go wrong.

Neither is actually a solution — one just moves the tedium, the other just moves the risk. So I built Mailwarden. Here's what running it on my own real inbox showed, and the three decisions that made it possible.

The inbox isn't 6,010 things. It's 261.

The first insight is almost embarrassingly simple once you see it: nobody's inbox is actually thousands of independent problems. On my own account, 6,010 messages broke down to 261 distinct senders. Newsletters I subscribed to once. Promotional blasts from things I signed up for years ago. Notification digests I've never opened.

The number of real decisions — does this sender matter or not — was never 6,010. It was 261. Message count was just noise multiplying a small number of real choices.

So Mailwarden classifies at the sender level, not the message level: aggregate everything from one sender, show the evidence, make one decision that applies to everything from that source. That's a 23× reduction in decisions for a person — and because classification runs once per sender instead of once per message, it's also roughly a 100× reduction in inference cost.

Those aren't two separate wins from two separate design choices. They're the same fact from two directions: fewer decisions for a human is fewer classifications for a model, because they're counting the same 261 things. That ratio is also what makes a genuinely useful free tier survive on a tight model budget at all.

It is structurally incapable of permanently deleting anything

Here's the decision I spent more time on than any other, and the one I think matters more than the speed.

I didn't want to promise "we'll be careful with your data" and ask you to believe me. I wanted a constraint that didn't depend on my code being bug-free, or my intentions staying good, or the app still existing next year.

Gmail's API offers a scope called mail.google.com that grants full access, including permanent deletion. Mailwarden never requests it. It requests gmail.modify instead — which can archive, label, and trash, but cannot permanently delete. Google will not grant that capability under this scope, full stop.

I built this constraint before I built the product, on purpose. If it doesn't hold, nothing else — the speed, the interface, the classification accuracy — matters at all.

It also isn't only a trust argument; it's an economic one. Google's app-verification process prices access tiers by what an app can do. The tier that allows full mailbox access runs roughly $4,500/year to maintain. The tier that matches gmail.modify runs $540–$1,800/year. One decision bought three things at once: a real undo guarantee, a claim no full-access competitor can honestly make, and a compliance bill I can actually afford as a solo builder.

Consent isn't a checkbox — it's the interaction model

Every batch follows the same loop: preview, explicit approval, execute, receipt. Nothing moves without a click on a screen showing exactly what is about to move — and the count on that screen isn't a rough estimate. It's produced by dry-running the real safety policy before you ever see it, so the number on the tile is exactly what will happen when you click.

A tile that promises 2,341 and delivers 1,800 destroys trust faster than a tile that never existed. Every message's prior state is recorded before anything changes, which is what makes undo exact rather than approximate — reversing a batch doesn't guess at what it looked like before, it replays what was actually recorded.

What it looked like on my own inbox

I connected my real account — the one I'd been avoiding cleaning up for years. Mailwarden synced 5,998 messages in 189 seconds and aggregated them down to 261 senders. The classifier resolved 45 ambiguous senders in a single model request.

Of 5,882 classified messages, 401 were locked as untouchable — 6.8%. Every sender I'd have been upset to lose was in that set: Google Accounts, my bank, a payments processor, and all eleven human correspondents I'd ever replied to. The other 5,481 were promotional blasts, notification digests and newsletters.

Getting there took finding four bugs that no synthetic test inbox would have caught. The worst one: a single stray reply used to lock an entire bulk sender as personal, which made 1,964 messages — a third of the mailbox — permanently untouchable. Reply detection is now a ratio rather than a boolean. Messages wrongly locked fell from about 56% to 6%.

Where things actually stand

I'd rather you know the real state than find out mid-signup. Google's OAuth verification review is complete, so sign-up is open to anyone and the old 100-user cap is gone. Mailwarden is still run by one person, so payments are confirmed by hand and there's no uptime guarantee worth calling one.

Pricing is deliberately shaped around the fact that inbox cleanup is a job, not a habit. The free tier clears 1,000 messages a month — roughly a month of ordinary promotional mail, so an inbox that's under control never pays. The Backlog Pass is ₹299 once for up to 50,000 messages, because clearing years of accumulation is something you do once and should be charged for once. Pro is ₹149 a month, and the only thing it sells is the scheduled re-scan that genuinely recurs.

Why I'm writing this instead of just linking the app

The pitch isn't really "clean your inbox fast," even though that's true. It's "you shouldn't have to trust a tool with data it doesn't need, or power it doesn't need to have." Sender-level aggregation is what makes the speed possible. gmail.modify is what makes the trust possible. I think the second one is the actual product, and the first is just what makes it usable day to day.

This is article one of a series opening the whole thing up — the sync and classification pipeline that turns thousands of messages into a couple of hundred decisions, the single chokepoint every mailbox mutation has to pass through, and exactly what does and doesn't reach a third-party model when the classifier needs help.