1
0 Comments

We fixed 12 bugs in one day, tested the weekly auto-clean end-to-end, and here's what we learned (+ we need your help)

Quick recap if you're new here: I'm building InboxClean — a Gmail cleaner that scans your last 1,000 emails, groups them by sender, and lets you unsubscribe + trash everything in one click. Pro users get this done automatically every Monday morning.

We got our first paid user last week. Still riding that high.

But today was a different kind of day — the unglamorous, heads-down, fixing-things-that-were-quietly-broken kind.


What we fixed today

After our first paid user signed up, I decided to do a proper audit. Not a quick scan — a real, line-by-line review of every API route, every database write, every edge case.

Here's what I found (and fixed):

1. Duplicate senders in scan results
LinkedIn was showing up twice. Microacquire was showing up twice. Any sender with multiple email addresses from the same domain was being treated as separate senders.

The fix: group everything by domain, not by email address. One click now handles every email from @linkedin.com — not just one variant of it.

2. The weekly auto-clean was silently failing
The cron job was running fine. But it was using the anon Supabase key, which was blocked by Row Level Security on a new table I'd created. So the results were getting cleaned but never logged. And the report card on the dashboard was showing nothing.

Fixed by switching to the service key and disabling RLS on that table. Lesson learned: always test your writes, not just your reads.

3. Refresh tokens were being overwritten with nothing
When a user signed in, there were edge cases where a valid refresh token in the database was being overwritten with undefined. Silent data loss. This would've caused auto-clean to fail for users after their access token expired.

4. The unsubscribe route had an SSRF vulnerability
A malicious unsubscribe link could've pointed to an internal network address. Added a guard that blocks private IP ranges before hitting any unsubscribe URL.

There were 8 more — ranging from a missing null check on the Paystack auth URL to the shield route writing to the DB even when the Gmail filter creation had already failed.


Then we tested the full weekly auto-clean end-to-end

I revoked Google access, re-authenticated to get fresh tokens, then triggered the cron manually.

Result: 42 senders cleaned. 368 emails trashed. 0 errors. ~12 minutes for the whole thing.

That felt really good.


Where we are now

✅ First paid user
✅ Weekly auto-clean working end-to-end
✅ 12 bugs fixed and deployed
✅ Launching on Product Hunt this Wednesday
⏳ Still waiting on Google's OAuth verification (the scary warning
screen is still there — users have to click "Advanced" →
"Go to InboxClean" to proceed)


Here's where I need your help
The Google verification process is the single biggest thing hurting us right now. Every new user sees a warning screen before they can even try the product. We know it kills conversion — we just can't control the timeline.

But there are things you can help with:

1. Try it and tell me what breaks
inboxclean.email — free plan gives you 10 unsubscribes. I want to hear every friction point, every confusing moment, every thing you expected to happen that didn't.

2. If you've been through Google's CASA/OAuth verification process
I would genuinely love to talk. How long did it take? Did you use a third-party auditor? Was it worth it at an early stage?

3. Upvote us on Product Hunt this Wednesday
I'll drop the link here when it goes live. If you've ever had an inbox you were ashamed of, this one's for you.


This is still very early. But every bug fixed, every test passed, every user who sticks around — it's all pointing in the same direction.

Building in public. Thanks for following along. 🙏

posted toAvatar for product InboxClean
InboxClean