DEV Community: Vivek Singh

Why I Index Only 32k Companies When Apollo Has 250M: A B2B Database Trade-off

Vivek Singh — Sat, 09 May 2026 15:23:10 +0000

One of the questions I get from prospects evaluating findmemail.io against Apollo or ZoomInfo: "your database is so much smaller — why?"

The honest answer: it's a deliberate trade-off, and the smaller-but-cleaner approach actually wins for the use case I'm targeting. Here's the architecture reasoning.

The "more contacts = better" myth

Big B2B databases brag about contact count: Apollo claims 250M+, ZoomInfo claims similar, Seamless says 1.8B+ emails. The implicit promise is that more = better.

In practice, more contacts = more stale records. Industry-standard B2B contact churn is ~3% per month — meaning a 250M database loses ~7.5M valid records every month. Re-verifying all of them at that scale is expensive enough that the providers don't do it on every entry; they batch-verify, delay flagging stale records, and let the "verified" status drift.

The result: a "verified" Apollo email has, on average, a 5-15% chance of bouncing depending on how recently the record was touched. ZoomInfo numbers are slightly better because they invest more in verification, but still meaningfully > 2%.

Why bounces matter more than database size

Cold email deliverability is gated by sender domain reputation. Once your domain trips a bounce threshold (~5% per send window), Gmail and Outlook start filtering everything from you to spam. Recovering domain reputation is slow and uncertain — sometimes you have to burn the domain entirely.

So the practical question is not "how many contacts can I get" but "how many contacts can I send to without burning my domain." A 1,000-email list at 1% bounce rate is more sendable than a 10,000-email list at 8% bounce rate.

The architectural choice

When I designed findmemail.io, I made one constraint up front: never return an email we haven't SMTP-verified at request time. Not pattern-matched, not domain-validated, not cached from a 6-month-old probe. RCPT-TO check, fresh, on every lookup.

That constraint determines the database size:

We can't index 250M companies because we'd need to constantly re-verify their emails. SMTP probes have rate limits, IP-rotation costs, anti-spoofing requirements. Doing it at 250M scale would be a multi-million-dollar/year infrastructure problem.
We CAN index 32k+ companies and re-verify aggressively. That's the size of the manageable-quality bucket.

What this means for users

The trade-off:

Apollo (large database)	findmemail.io (smaller, fresher)
250M+ contacts	32k+ companies
~5-15% bounce rate	<2% bounce rate
You build broad lists	You build precise lists
Per-seat pricing	Lifetime tier

For a 10,000-person sales org needing to spray-and-pray on a contact firehose, Apollo's size is the right answer.

For an indie founder targeting a precise ICP at indie-founder volumes, the smaller-but-cleaner database wins. You're not trying to send to 50M people. You're trying to send to 500 right people, get verified emails for them, and not burn your domain.

Implementation notes (for builders curious about the SMTP layer)

The SMTP probe at request time is the hard part. Quick architecture sketch:

client → API → cache(7-day TTL) → SMTP probe pool → MX server → response

Probe steps:

MX lookup for the recipient domain
TCP connect to MX on port 25
HELO/EHLO with throwaway sending domain
MAIL FROM with throwaway sender
RCPT TO with target email
Read response (250 = accept, 550 = reject, 421/451 = retry)
QUIT — never DATA, never deliver

Anti-detection challenges:

Mail servers rate-limit probes per source IP. Need an IP rotation pool.
Some servers (Google Workspace, Microsoft 365) refuse RCPT-TO probes entirely — return 252 for everything. We fall back to historical pattern data for these.
Catch-all detection: probe a known-bad address first; if it returns 250, the domain is catch-all and we don't return individual emails.
Greylisting: server returns 451 first, expects retry. We retry with backoff up to 3x across an hour.

This pipeline runs on every lookup. P50 response time is ~800ms, P95 is ~2s. Caching for 7 days keeps the per-domain load reasonable while keeping freshness within typical B2B contact churn windows.

What I'd build differently if I had a $10M budget

Honest answer: I'd still cap database size, but I'd index more precisely.

Keep the 32k → 100k+ companies range, not 1M+
Add intent signal layer (job changes, funding rounds) — currently you have to pair with Pharow or Clay
LinkedIn-derived enrichment, but only for verified + active accounts
Better dedup on people-who-changed-jobs (currently a manual step)

The thing I would NOT do: chase Apollo's 250M number. The trade-off doesn't favor it for the indie founder ICP.

Try it

findmemail.io — free tier on signup, 50 credits, no card. Run the same query you'd run on Apollo and compare the bounce rate on a small batch. The architecture-driven quality difference shows up immediately.

TL;DR

Database size is the wrong KPI for B2B email finder quality. Bounce rate is the right one, because bounce rate determines whether your sender domain stays sendable. Smaller databases with aggressive re-verification beat larger databases with stale records — at indie-founder volumes. That's the architectural bet behind findmemail.io.

How I built SMTP email verification at scale for findmemail.io

Vivek Singh — Sat, 09 May 2026 12:55:27 +0000

When I started building findmemail.io, I made one architectural decision early: never return an email we haven't SMTP-verified at request time. No pattern guessing, no domain-only validation. This post is about how that constraint shaped the system.

Why SMTP verification at request time

Most B2B email finders do verification asynchronously, in batches. The result is a database where some entries are verified, some are stale, some never were. Users don't know which is which.

This kills cold email deliverability. A 5% bounce rate flags your sender domain. A 30% bounce rate (common with mixed-quality data) burns it.

The constraint at findmemail.io: every email returned to the user has been SMTP-probed in the last 7 days. If it's older or the probe failed, we don't return it.

The SMTP probe

For each candidate email, we do:

MX lookup — find the recipient's mail server
TCP connect — open port 25 to the MX
HELO/EHLO — introduce ourselves
MAIL FROM — declare a throwaway sender
RCPT TO — ask the server if it'll accept the recipient
QUIT — close cleanly, never DATA, never deliver

The key step is RCPT TO. The server returns:

250 — accept (email exists, deliverable)
550 — reject (mailbox doesn't exist)
421/451 — temporary failure (greylist or rate limit)

We classify each result and only "250" emails get returned to the user.

Anti-anti-bot: how mail servers fight you

This sounds straightforward but isn't, because mail servers actively fight verification probes. Common defenses:

1. Catch-all domains. Server returns 250 for any address. literally.anything@catchall-domain.com "accepts". Useless.

Detection: probe a known-bad address (asdf-not-a-real-user-12345@<domain>). If that also returns 250, the domain is catch-all. We tag it and don't return individual emails for the domain.

2. Greylisting. Server returns 451 the first time, expects a retry. Real mail servers retry; one-shot probes don't.

Mitigation: retry the probe with exponential backoff up to 3 times across 1 hour. Track which domains require this.

3. Rate limiting per IP. Send too many RCPT TO requests, you get throttled or blacklisted.

Mitigation: rotate sender IPs, never probe the same domain more than 1x/min, distribute load.

4. Anti-Spoofing. Server checks SPF/DKIM on your sender domain before responding to RCPT TO.

Mitigation: maintain a real, warmed-up sending domain with proper SPF/DKIM/DMARC. Use a different domain than your product domain.

5. Honeypot / tarpit. Server responds slowly to waste your time. Or returns 250 for every address to pollute your dataset.

Detection: time the response. >5 sec = suspicious. Cross-check by probing 2-3 known-good emails on the domain — if they all "accept" but bounce when actually sent, flag the domain.

The cache strategy

Probing on every request would be slow and rude (you'd hammer the same MX). So:

First-time probe → cache result for 7 days
Re-probe on cache miss
Re-probe sooner if the user reports a bounce (feedback loop)
Background re-validation for top 1000 most-queried emails daily

This keeps p50 response time under 800ms while maintaining freshness.

Failure modes I had to learn the hard way

Major email providers (Google, Microsoft, AOL) often refuse RCPT TO probes entirely. They return 252 ("can't verify, try sending") for everything. That's because so many spammers used SMTP probing to harvest valid addresses that the providers gave up on telling you.

For these domains, we fall back to:

Pattern matching against historical sender data
LinkedIn-based name verification
Domain-pattern enrichment (if other emails at the company verified, the same pattern likely works)

We label these as "deliverable, lower confidence" in the API response. The user sees the difference.

What this enables

Because every email is verified at the call site, our customers get a bounce rate <2%. Compare that to the typical Apollo/ZoomInfo ~5-10% in industry reports.

This was the design constraint that shaped everything else about findmemail.io — the database is smaller than Apollo (32k+ companies vs millions) but the per-email quality is much higher.

Try it

Free tier on findmemail.io is 50 credits, no card required. The API returns deliverability confidence per email so you can decide which to send.

If you're shipping a B2B email finder yourself, feel free to ask architecture questions in the comments.

Plain-English search beats filter UIs for B2B email finders — here is why

Vivek Singh — Sat, 09 May 2026 12:42:05 +0000

The problem with filter UIs

Most B2B email finders (Apollo, Hunter, ZoomInfo, Lusha, Cognism) ship a filter sidebar with 6-12 dropdowns: industry → sub-industry → company size → role → seniority → location → funding stage → tech stack → headcount growth → and so on. To build a list, you click through every one.

In practice, this means:

you have to know each tool's category taxonomy
"industry" lists in different tools don't match (one calls it "Mining & Metals", another "Materials")
you can't describe a niche cleanly ("VPs of operations at copper mines in Chile" doesn't map to any standard filter)
every list you build takes 5-10 minutes of clicking before you even hit search

What plain-English search changes

I built findmemail.io because I was tired of the click-through workflow. The core idea: type the ICP in one line, get verified emails back.

Examples that work today:

"VPs of growth at Series A SaaS in NYC"
"founders of seed-stage climate tech in Berlin"
"CMOs at consumer SaaS with 50-200 employees"
"agency owners doing performance marketing in India"

The query gets parsed into structured filters server-side, matched against the company graph, then SMTP-verified emails are returned.

What I learned shipping it

A few things were surprising:

1. Most queries don't need a filter UI at all. When users could type freely, ~80% of queries fell into 6-7 patterns: founder/CEO + stage + industry, VP/Director + function + region, etc. The filter UI was solving for a long tail of edge cases that almost nobody hit.

2. SMTP verification matters more than database size. A list of 1,000 verified emails outperforms 10,000 catch-alls — bounce rate kills sender reputation, and once you're flagged, every campaign suffers. We index 32k+ companies but the value is the per-email verification.

3. Pricing models are the real differentiator. Most tools sell credits + monthly subscriptions. Indie founders hate subscriptions and want predictable cost. We ship a $200 lifetime tier with 7-day refund — no recurring billing, no per-seat. Conversion on this tier outperformed monthly 3:1 in early months.

Stack notes for builders

semantic parsing of the query: small fine-tuned model + structured filter extraction
company graph: combined from public registries, LinkedIn-style sources, and crawled domains
email finding: pattern enumeration + MX/SMTP probe per pattern
verification: throwaway sender + RCPT TO check, no DNS-only "valid format" checks

Why the build-in-public version

I'm sharing the architecture and lessons because most "B2B leadgen" content online is recycled SaaS marketing. Indie founders shipping in this space need actual signal, not best-of lists.

If you're shipping a leadgen workflow and want to try plain-English search instead of filters: findmemail.io — free tier on signup, 50 credits to play with.

Happy to answer architecture questions in the comments.

What I learned shipping a B2B email finder as a solo founder

Vivek Singh — Sat, 09 May 2026 09:40:17 +0000

Six months ago I shipped findmemail.io, a B2B email finder built around plain-English search instead of filter pickers.

Sharing the things I'd do differently if I started over today, in case it's useful to anyone in a similar spot.

what worked

plain-english search as the wedge. every existing tool in this space (apollo, hunter, zoominfo, lusha) makes you click through 5-8 filter dropdowns to define an ICP. it works once you learn it, but the first-run experience is brutal. i let users type "VPs of operations at copper mines in chile" and the system parses + filters. early activation rate jumped 3x vs the filter ui i originally shipped.

lifetime pricing for the bottom of the market. subscription pricing forces the smallest customers to either pay full SaaS rates or churn immediately. a $200 one-time tier serves the indie founder/freelancer segment that big tools deliberately ignore. these users are also the loudest evangelists when something works.

verification waterfall over single-source. every "verified" email has a non-trivial bounce rate. running every result through 2 independent SMTP checks before serving it cut bounces from ~12% to under 4%. higher infra cost, but the alternative is users blaming you for sender reputation damage.

what i'd do differently

ship the public landing page before the product. i spent 3 months building before showing anyone a URL. should have launched a landing page with the plain-english search demo on day 14, taken a waitlist, and used the wait list as my user research panel for the next 6 weeks.

don't try to compete on database size. i wasted an entire month chasing data volume to match apollo's 200M+ contacts. nobody cares. a 32k-company index that's actually fresh and well-verified beats a 200M-company index that bounces at 20%. focus on a tight TAM and serve it well.

charge from day 1. my first 50 users were all free. 47 churned. the 3 who paid stayed for 6+ months. the lesson wasn't "free is bad", it was that paying users self-select for ICP fit, and free users mostly don't.

what i'm working on now

distribution. the build was the easy part. for an indie b2b tool with no warm network, the only real channels are: founder LinkedIn, communities where your ICP already hangs out, and very narrow paid retargeting. ad spend before product-market fit is just expensive education.

happy to answer questions if anyone is shipping in this space.