How efficient is your deal flow? Enter how many startups pass through each stage of your pipeline and see conversion rates, drop-off points, and where you sit versus typical early-stage VC fund benchmarks.
| Stage Transition | Input | Output | Conv. Rate | Drop-off | vs Benchmark |
|---|
Benchmarks reflect typical angel/micro-VC through Series A funds. Top-decile funds convert 2-3× better on the seen→closed metric. Your mileage will vary with thesis tightness, sector, and whether you lead or follow.
For early-stage funds, ~0.5-1.5% of deals seen ultimately close. Top-decile funds cluster around 2-3% because they have a sharper thesis and see better deal flow upstream. Below 0.3% usually means you're sourcing too broadly or screening too loosely.
The biggest drop is almost always seen → screened (~70-80% attrition is normal). The most diagnostic stage is meeting → term sheet: if that's below 15%, you're taking too many low-conviction meetings. If term sheet → close is below 40%, your terms or founder relationships need work.
At a typical 1% overall conversion, you need ~100 qualified deals seen per quarter to close one. That's why solo GPs and micro-funds rely heavily on proprietary screening signals, like GitDealFlow's GitHub-velocity data, to compress the funnel without sacrificing quality.
This calculator exists to be embedded in a sourcing or diligence workflow, not used once and closed. The numbers it produces are the same primitives the GitDealFlow dataset is built on: 350+ startup GitHub organizations tracked across 15 sectors, refreshed weekly. When a target company is being evaluated, run its figures here, then compare against the sector baseline in the research dataset. The disciplined pattern is signal first (breakouts surface 21 to 47 days before the round), then arithmetic (does the unit economics justify a meeting), then process (memo, checklist, decision).
A practical read-through of Deal Flow Funnel Calculator: the dataset behind this page refreshes weekly across 350+ organizations and 15 sectors, and every figure shown traces to a public GitHub REST API pull. That matters for two reasons. Reproducibility: any number here can be re-derived from primary sources, which is the standard the published methodology sets for itself. Timeliness: engineering acceleration precedes announcements, so this page follows the data cadence rather than the news cycle, and the freshness endpoint always reports the exact pull date.