I build the pipeline
under the tools.

One person to run the entire outbound function. Build the contact database, run the campaigns, keep the CRM straight, maintain sales sheets and invoice logs. No team, no existing list, no tooling budget.

Because I was the scraper. 150 websites a day. Open site, find contact page, copy email, copy phone, paste into the spreadsheet, repeat. Eight hours a day. Eyes sore by noon.

London property is fragmented and hyperlocal — letting agents, block managers, estate agents, care homes, restaurants — spread across every borough with no single directory covering them, and badly under-indexed by Apollo and Sales Navigator precisely because it's niche. Each borough was its own manual sweep.

The one thing working in my favour: compliance has a natural trigger event built in. Certificates expire on a schedule. A prospect with an expiry coming up is a fundamentally different lead from one without — and targeting on that beat any static "owns property in London" list I could have built.

Almost every email I collected started with info@.

That's what a website's contact page gives you. Generic inboxes, watched by a receptionist or an auto-responder, nobody with buying authority behind them. I'd built a 10,000-row database that was technically accurate and commercially close to useless for cold outreach. The outreach failed, and for a long time I assumed it was the copy.

Two changes. First, stop treating "an email exists" as the finish line — the record isn't done until there's a named person with a title attached. Second, source contacts where names actually live: Apollo, company team pages, LinkedIn — not the contact form.

That's also where the three-bucket verification standard came from. Role-based addresses stopped being "a contact with a slightly worse email" and became their own category — dropped from sends entirely, flagged for a different channel if the account was worth chasing another way. Everything in section 04 is the formalised version of what I learned here the hard way.

I asked to automate the sourcing so I could spend that time on qualification instead of copy-paste. The answer was no.

They ended up with a 10,000+ contact database segmented by borough, business type and portfolio size, plus a full audit trail across sales sheets, invoice logs and service records — one row per prospect, not per email, so the sales team had a single source of truth rather than a touch log.

Volume was fine. Deliverability looked fine on the surface. The sequences were built properly and going out on schedule. The replies just weren't there — and the few that came were almost all out-of-office.

A thousand sends is enough that "bad luck" stops being an explanation. At a normal 2–3% you'd expect twenty-odd replies. I had a handful. So I stopped optimising the copy and went back through the list itself.

99% of those emails were landing in generic inboxes — info@, contact forms, auto-responders. Not real inboxes. Filters, managed by people with no budget authority and every incentive to mark an unsolicited email as spam.

I proved it by segmenting the sent list by address type. Every reply I'd received — every single one — came from a named contact at a person@company.com address. Same campaign, same product, same period, same copy. Only the recipient type differed.

Underneath that, a second problem: no SPF, DKIM or DMARC checks in place. Every send into a generic inbox that got marked as spam was quietly training filters against the sending domain. Volume wasn't neutral — it was actively making things worse.

• Strip every generic address out of the list before a campaign goes live
• Re-source named contacts by title and company size through Apollo and company sites
• Verify SPF, DKIM and DMARC before sending anything
• Segment generic vs named — never send the same sequence to both
• Personalise by role, company size and a specific pain point, not by mail-merge token

Reply rate on named, personalised contacts: around 7%. Roughly seven times the generic-inbox result.

Same copy. Same tools. Same sender. The only variable that changed was who was on the list.

For reference, my standing benchmark is 8–10% on properly targeted, personalised sends versus 2–3% on bulk — roughly a 3–4× spread. The 7% here is the recovery from a broken campaign, not a best case.

Directories and Google Maps for ground-level coverage, because a good part of this segment barely exists on LinkedIn — a Sales Navigator-only approach would have missed it. Then cross-referenced through Sales Navigator and Apollo to attach names and titles.

1,000 raw prospects in the pool. Then the real work started.

Every stage removed prospects. The reply rate is high because the list is small, not the other way round.

• Pass 1 — hard filters. Remove everyone outside the 5–50 employee range, wrong title, wrong geography.
• Pass 2 — named contact or out. A real person with a real email. Not info@. Not contact@.
• Pass 3 — manual review. Every remaining contact read individually against the full ICP. Decision-maker title confirmed, company size confirmed, location confirmed.

70 passed. A 7% survival rate.

Because a thousand-row list isn't an asset, it's a liability with a spreadsheet around it. Every unqualified send is a chance to get marked as spam, and that damage lands on the sending domain — which then degrades the sends to the contacts who were qualified.

Volume doesn't just waste effort. It actively taxes the part of the list that would have worked.

Those 70 got a personalised, well-structured email — written against a tight enough ICP that the same pain point was genuinely true for all of them, which is only possible because the list was small.

49 of the 70 replied — 70%. Of the people who replied, a quarter went on to buy. The client was selling a SaaS product, so the purchase rate is the number that mattered to him, and it is the one worth judging the work on.

Four to six hours to deliver a single lead list to one client. Most of it wasn't scraping — it was the cleaning, merging, reformatting and delivering afterwards. And because nothing was stored, I couldn't answer "did we already scrape this?" without opening old folders.

python run_batch.py --tag "digital marketing agencies london" \
       --scrapers google_maps trustpilot

Both scrapers run simultaneously in the background. 118 leads from Google Maps (66% with email, 89% with phone), 458 from Trustpilot (96% with email). Normalised, merged and deduplicated automatically. 576 rows delivered to Google Sheets in 49 minutes, completely unattended.

• Plugin system — any scraper that returns a list of records connects to the pipeline without touching downstream code. Adding a source is one new file.
• SQLite storage — every run saved with a unique run_id, scraper name and timestamp. Permanent searchable history.
• FastAPI layer — four endpoints to trigger runs, query results and push to any Sheet.
• Schema-flexible — Maps returns Rating, Trustpilot returns Trust Score, Yell returns review_count. None of them have to match. The pipeline stores all of them.
• 100+ automated tests covering the API layer, storage, normalisation and delivery. The captured run in the proof section shows 84 passing in 4.34s — that was the suite at the time of the screenshot; it has grown since.

The hardest bug wasn't in the scraping — it was a session-timing problem in the multi-engine search tool that feeds this pipeline.

DuckDuckGo uses a POST endpoint. A cold session returns HTTP 202 — not a ban, not an error, just silence. Zero results, no exception, nothing in the logs to tell you anything went wrong.

The first version warmed up every session at startup, then ran Mojeek — which takes 10–15 minutes on a large file. By the time DuckDuckGo's turn came, its session had expired. I was silently losing an entire engine's worth of leads on every run and the tool reported success.

Fix: move the warmup inside the engine loop, immediately before that engine's first request. One line moved. It's in the CHANGELOG.

Second one worth naming: requests.get(url, timeout=10) sets a socket inactivity timeout, not a wall-clock limit. A server that accepts the TCP connection then goes silent will hang the thread indefinitely. On a 1,000-site run, three or four of those stall everything. No error, no exception. The fix is running the request in a daemon thread and joining with a hard wall-clock limit.

The six tools it orchestrates are public and MIT-licensed. The pipeline that runs them together is not.

It took weeks to get the architecture right and it's the thing that makes a delivery take 49 minutes instead of six hours. That's the product, not a portfolio piece.