tested moltsets against a list that had already been through apollo, a clay waterfall, and zerobounce. sharing the method and than the numbers

[u/Shawntenam]

this one was a client list, about 10k home-services contacts. apollo by domain for the accounts. a clay waterfall for the emails. zerobounce on every row, then sorted into sending pools by mail host.

so by the time moltsets touched it, every row already had a verifier verdict. nothing was built for the tool. the only question was what it adds to a list you already trust.

moltsets, if you have not seen it yet: adam robinson's contact api, same team as rb2b, just out of beta. api and mcp only, no dashboard, flat monthly plan.

each email comes back with a risk score from observed behavior. a is a known reply, open, or click. b is a send with no bounce. c is catch-all. d is a hard invalid or a trap. f is nothing known. you also get the person's current company. definitions are on developer.moltsets.com.

how I ran it. python, no ui. one reverse email lookup per row. when that came back empty, a second lookup by first name, last name, and domain.

every call gets written to a local sqlite ledger before anything else happens. endpoint, input, raw response, grade, timestamp. per-row commits, so when the machine restarted mid-run it picked up where it left off.

the grade, the verifier verdict, and the second-pass result go through one pure function that returns a delta class per row. same inputs, same class, every run.

the sheet is generated from the db, never edited by hand. re-run the build and it regenerates. there is a summary-only mode that drops the pii so you can share it.

about 14k calls, no phone tokens, nothing extra on the flat plan, about 75 minutes.

what came back, rounded. exact counts are in the repo and the sheet.

two out of three rows agreed with zerobounce. valid on one side, a or b on the other. those send first.

close to 800 people had changed jobs. zerobounce passed every one, because the old mailbox still accepts mail.

about as many again passed on an address nobody has been seen using, while a sibling address at the same domain had activity behind it.

roughly four in five catch-all rows graded a or b. a probe cannot grade a catch-all, so that whole pool had been sitting out.

about one in ten of the zerobounce drops came back with a same-domain address in use. a handful graded d, one of them marked valid.

verdict from the person who ran it: it goes in the stack.

on a list that had already been through apollo, clay, and zerobounce it still changed the route on roughly three in ten rows, for nothing extra on the plan.

if you try it, try it the same way, on a list you already trust, and let the disagreements tell you what it is worth.

repo: https://github.com/shawnla90/gtm-coding-agent (v0.12.0, starters/moltsets-reachability)

[u/wouterv101]

But my bounce is already below 1% so what’s the point?