A B2B prospecting pipeline I built because the off-the-shelf sales tooling didn't fit how a freight company actually sells.
Django + Supabase/Postgres, structured as real modules — leads/, companies/, enrichment/, campaigns/, analytics/, browser/, services/, api/, core/ — with pytest and .env / .mcp.json config so it runs the same way twice.
The pipeline
Sales Navigator ──(browser)──> Supabase ──> Apollo ─┐
├─> merge + score ─> verify ─> Instantly
RichAPI / TexAu ────┘- Discover — drive LinkedIn Sales Navigator through Kimi WebBridge: a real browser with a real logged-in session, because Sales Navigator has no API worth the name.
- Store — prospects land in Supabase as
found, no email yet. - Enrich — fan out to Apollo and RichAPI/TexAu, merge results back with confidence scores and source attribution.
- Verify — MillionVerifier / Instantly check deliverability before anything is allowed to send.
- Campaign — only verified contacts get pushed into Instantly.
What I learned building it
The browser layer is architecture, not a hack. The highest-signal source in the pipeline is the one you can only reach by driving a logged-in session. I went in assuming that was the embarrassing part I'd replace later with a proper API. There is no proper API. Designing around that up front — treating the browser as a first-class, retryable data source with its own module — made everything downstream simpler.
Every stage lies to you differently. Enrichment returns confidently wrong emails. Two verifiers disagree about the same address. The same human arrives three times under two spellings and a diacritic. I budgeted my time for API integration and spent it almost entirely on reconciliation: dedup, confidence scoring, deciding which source wins when they conflict, and keeping the provenance so I can tell later why a record looks the way it does.
Verification before send is non-negotiable. Sending to unverified addresses damages a domain you can't un-damage. Making the verify step a hard gate rather than a warning was the single highest-value design decision in the system.
Built by someone with twenty years in logistics and no CS degree — the advantage being that I knew exactly which manual process was eating my week before I wrote a line of it.