Playbook · operator how-to
How to spot a pre-seed round from commit-velocity (11 weeks early)
A signal-reading playbook that catches pre-seed rounds 8–14 weeks before they're announced — using only public GitHub commit-velocity, contributor influx, and infrastructure build-out signals.
Pre-seed rounds are public information ~8–14 weeks after the wire actually clears. The signal that they're about to be announced is in the GitHub repo, usually starting 4–6 weeks before the announcement.
The two co-occurring signals are: (1) commit velocity accelerating on a 28-day rolling — usually by 40–80% over the prior 28-day baseline — and (2) contributor influx, where two or more new committers appear within a 14-day window. The first signal alone is just shipping momentum; the second alone is just open-source contribution. Together, they're almost always "the founders just hired their first two engineers with the cheque they raised".
This playbook gives you the exact watchlist mechanic — how to set it up, what threshold to alert on, and how to read the resulting signal without front-running false positives.
Before you start
Prerequisites
- · A starting list of 50–200 repos to watch (any niche)
- · A way to fetch the signals feed on a weekly cadence (cron + curl is fine)
Tools
- · GitDealFlow signals feed
- · Spreadsheet or simple database
- · Email or Slack for the alert
Steps
- 01
Build the watchlist
15mStart with 50–200 repos. Any source works — your starring history, the top-25-by-sector pull from the public feed, or a hand-curated list of orgs you respect. The key is that the list is stable across weeks so you can compute deltas.
- 02
Pull commit velocity weekly
10mOnce a week (Monday afternoon, after the feed refresh), fetch the commit-velocity 28-day percentile for each repo from
/api/v1/signals.json. Store the value. Compute the week-over-week delta. - 03
Pull contributor count weekly
10mSame cadence. Fetch the unique-contributor count for the trailing 14 days for each repo. Store it. Compute the week-over-week delta.
- 04
Set the co-occurrence alert
5mAlert when ALL three are true in the same week: (a) commit-velocity 28-day percentile increased by ≥ 15 points week-over-week, (b) two or more new contributors appeared in the trailing 14 days, (c) the repo has CI workflows configured. The CI gate cuts out the most common false positive — a sudden burst of cosmetic README contributions from drive-by contributors.
- 05
Confirm with a 15-minute manual read
15mWhen the alert fires, open the repo manually. Look at the commit messages from the new contributors — if they're substantive feature commits (not docs or typo fixes), the signal is strong. If they're surface-level, downgrade to watchlist.
- 06
Schedule the outreach for week 4
5mDon't email the day the signal fires. Wait three to four weeks. By then the founders are usually post-honeymoon-period with the new hires and have headroom for a coffee. Outbound at week 4 has a much higher reply rate than at week 1, in our experience.
Run the play
Read the full methodology →Frequently asked questions
Why wait three weeks before outreach?
Reply rates roughly double at week 4 vs week 1 in our internal tests. Founders in the immediate post-close window are absorbed with onboarding new hires and announcing the round. By week 4, they have headroom and are actively looking for design-partners / next-round intros.
Does this work for seed and Series A too?
Less reliably. Seed and Series A rounds tend to be preceded by hiring announcements, blog-post drafts, and trademark filings — the signal mix moves off-platform. Commit-velocity still rises but the lead time compresses to 4–6 weeks instead of 9–14.
What's the false-positive rate at the threshold above?
Roughly 9% in our validation set with the CI gate, 31% without it. False positives are usually open-source spikes — Hacktoberfest, a viral GitHub Action, or a popular import from a much larger project.