The Podcast Pipeline
Finds founders interviewed on small podcasts, reads the episode, and writes about what they said.
- Timeline
- 5,619 episodes · 867 prospects
- Role
- Solo: architecture, pipeline, cost ledger and state machine
- Status
- Built and running
- Primary stack
- Python · asyncio · PostgreSQL · OpenAI · Serper
Headline metrics
- What it tackles
- Writing to someone about what they said on the record is the strongest opener in cold email, and the hardest to produce at any scale.
- What it delivers
- A resumable six-module pipeline that read 5,619 podcast episodes, filtered them through named gates to 867 researched prospects with verified addresses and drafted emails, and priced every billable call to a 43,588-entry ledger while the run was still going.
Why I built it
I built this one because the best outreach I have ever sent was the outreach that referenced something the recipient had actually said, and it is also the hardest kind to do at any scale.
Founders say revealing things on small podcasts that almost nobody hears. If a system could find those episodes, read them, and write about what was said, every email would arrive with a reason to exist. So I built it.
The problem in full
A founder who has sat through an hour-long podcast interview has already explained their business, their numbers and their problems, in their own words, on the record. Almost nobody uses that, because the people worth reaching this way are visible on camera long before they are visible in a B2B database, and reading thousands of episodes is either a manual job that stops at a handful or a model bill that grows with every row.
The engineering problem is sharper than the research problem. Acting on those episodes means running tens of thousands of paid API calls across seven providers without losing state, paying twice, or quietly failing halfway through. Search, video data, transcripts, verification, language models and sending each bill separately, several rate-limit, and on a long run one of them will fail. A design that treats any failure as a restart pays again for work it has already done.
The third constraint is that language-model cost scales with record count, not with record value. Spending the same on all 5,619 discovered videos would have decided the economics of the whole system before it had qualified anything. So the build is, above everything else, a machine for refusing to spend money until a row has earned it.
System design
This is a solo build, designed, written and run end to end for my own pipeline. The core of it is one wide table with one row per video and a status column per stage. Every stage claims only the rows its own status has not touched, which makes each stage independently resumable: a run that stops at row 4,000 of 5,000 picks up where it stopped instead of paying for the first 4,000 again. The outreach stage was resumed across five separate runs without losing or re-billing a row.
Discovery starts from three seed channels, the only manual research in the entire pipeline, and finds the rest itself by mining related channels and feeding every discovery back in as a source. Channels are promoted by which ones keep producing qualified guests, and three seeds became 117 channels. The run put 377 search queries through thirteen languages, reached 650 distinct podcasts, and admitted 5,619 long-form interviews filtered on views, duration and recency, with every appearance record completed from metadata before a single billable call was spent judging it.
Qualification spends nothing until the free checks are done. A 731-name suppression list is matched against video titles before any model is called, which blocked 358 rows outright. Web search then ties the guest to the company they actually run, and the cheapest model screens all 5,619 rows on metadata alone, discarding 65% before anything expensive touches them. Only low-confidence verdicts escalate to a stronger model, so certainty is bought exactly where it is missing. The 1,961 survivors yielded 1,946 transcripts, which a long-context model reads for exact figures and for problems the guest named unprompted, and a third model writes the draft. Even the right-person check runs four deterministic string rules before it spends an LLM call cross-examining a candidate.
Finding the address follows the same rule. A three-tier waterfall tries the address already sitting in the search result, then the company contact pages, then 34 structured permutations against the domain, verifying each candidate in turn and stopping at the first usable verdict, so spend per row is set by where the hit lands rather than by the length of the list. 889 unique addresses passed verification. Underneath all of it, every billable call is written to a cost ledger with its service, model, units and status, priced as it happens, 43,588 entries in all, so the cost of the run is a live measurement rather than an invoice read weeks later.
The calls that made it work
One wide table, one status column per stage
A long pipeline that cannot resume re-bills itself on every restart. Because each stage claims only rows its own status has not touched, any stage can stop and continue independently, and the outreach stage did exactly that across five runs without paying for the same work twice. On a pipeline touching a dozen metered providers, this is the mechanism that stops a call being bought twice.
Route models by what the task is worth
The cheapest model screens every row on metadata alone and discards 65% of them before anything expensive runs. A long-context model reads only the surviving transcripts, a third model writes only the qualified drafts, and the expensive tier touches only what the confidence check flags. The uniform design, the same model on every record, never runs, and that single choice is most of what the run cost turns on.
A contact waterfall that exits early and measures itself
Search result first, contact pages second, 34 structured permutations third, each candidate verified before the next tier is tried. The instrumentation showed the permutation tier produced 70.8% of all addresses while the contact-pages tier produced 2.4% at a fixed cost on every row, which makes the weak tier a named, evidenced candidate for removal rather than a cost nobody noticed.
Price every call to a ledger, live
Every billable call is logged with its service, model, units and status as it happens, 43,588 priced entries across the run. At any moment mid-run I can state what the pipeline has spent and what one contact has cost. That ledger is the only reason any figure on this page is a measurement rather than an estimate.
The results in full
867 prospects delivered, each with a verified work email, a research dossier drawn from the episode, and a drafted first email that quotes it, produced from 5,619 discovered videos across 650 distinct podcasts. The production rewrite delivered 867 drafts against 538 on the prototype, working from a channel set the system widened for itself from three seeds to 117. 889 unique addresses passed verification on the way, and every one of those counts is read out of the pipeline's own funnel tables, not reconstructed afterwards.
300 prospects went into the first campaign. The post-send module read the send record back, re-verified the risky addresses, and removed 63 undeliverables before they could be spent against sending reputation, the one asset in outbound that cannot be bought back. The list resolved to 237 deliverable addresses, and 567 prepared prospects stand ready for the next send. The system now runs as the pattern behind my other pipelines: keep state per row, run free checks before paid ones, route models by value, and meter everything while the run is still going.
Continue reading
The Enrichment Engine
A recruiting engine rebuilt to decide before it pays for data, then pointed at two more verticals.
The Model Router
Two trained classifiers behind an LLM agent that decides which one to call.
The Listing Auditor
A pipeline that audits a brand's live Amazon listing and writes the email about what it found.