The first time I almost called a fundraise wrong, I was looking at a contributor jump on a small fintech org. Five contributors to twelve in eleven days. Clean step function, the kind that shows up in a chart and makes you reach for Slack. I drafted a message to an investor friend — "this team raised, watch for the announcement in the next two weeks" — and then I caught myself. I'd seen the same exact shape fire six times that quarter, and only twice did it actually map to a round. The other four were a hackathon, a Google Summer of Code cohort, an open-source contributor sprint, and a team that committed under personal accounts so a re-org made the count jump.
I deleted the message.
That was the day I stopped trusting any single GitHub signal. After six months of watching commit traffic across roughly 4,200 startup orgs, I have five patterns I take seriously and one rule that holds them together: no signal fires alone. If I see one, I shrug. If I see two firing inside the same fortnight, I get out of my chair.
Pattern 1 — the contributor step function
The most-cited pattern is also the most fooled. A startup goes from 5 contributors to 12 in two weeks. The hypothesis is that the round closed, the team ramped hiring, and the new engineers are pushing first commits. The hypothesis is sometimes correct. It's often noise.
What I actually look for: a 50% jump in unique contributors sustained for at least 4 weeks, and the new contributors must show up across multiple repos in the org, not just a single docs sprint. If the new contributors only commit to one repo and disappear after 10 days, that's a hackathon. If they ship across the codebase and stick, that's hiring.
Here's the SQL I run weekly against my GitHub Archive mirror. Nothing fancy — but the join on last_commit_at is what kills the hackathon false positives:
WITH new_contribs AS (
SELECT actor.login AS user, repo.org AS org,
MIN(created_at) AS first_commit_at,
MAX(created_at) AS last_commit_at,
COUNT(DISTINCT repo.name) AS repos_touched
FROM gh_archive_events
WHERE type = 'PushEvent'
AND created_at BETWEEN now() - interval '60 days' AND now()
GROUP BY 1, 2
)
SELECT org, COUNT(*) AS retained_new_contribs
FROM new_contribs
WHERE first_commit_at >= now() - interval '30 days'
AND last_commit_at >= now() - interval '7 days'
AND repos_touched >= 2
GROUP BY org
ORDER BY retained_new_contribs DESC;
The repos_touched >= 2 filter alone drops about 40% of the false positives I was getting before. That number isn't theoretical — it's what the noise reduction looked like the week I added it.
Pattern 2 — the infrastructure explosion
Three to five new public repos appearing in the same org inside 30 days, and the new repos are infra-shaped: SDKs, internal tools, deploy configs, terraform modules. Not a fork sprint. Not a docs site spinoff. Real platform plumbing.
This one is rare, but when it fires it almost never fires alone. Companies don't invest in platform engineering speculatively — they do it when there's runway to spend on it. I caught a YC company doing this two months before their Series A announcement. The trigger was four new repos in a week named after AWS services, all created by the CTO, all with initial commits that read like checked-in scaffolding rather than code anyone had been working on locally.
The trick: read the first commit on each new repo. If the first commit is a 200-file git push with no prior local history, that's a private repo going public. If the first commit is a single README.md, that's somebody starting from zero. The second one is the interesting signal — fresh starts in infra-land mean the team has the breathing room to build new things.
Pattern 3 — weekend commits across multiple humans
A startup whose commit log goes from weekday-only to seven-days-a-week is racing toward something. The catch: weekend activity from a solo founder means nothing. They were always doing this. Weekend activity from three or four contributors, sustained for three weekends in a row, means there's a deadline.
The deadlines that produce this pattern, ranked by frequency in my data:
- A demo for a fundraise (usually Series A or later — pre-seed teams are too small to pull weekend ensembles).
- A product launch with a press cycle attached.
- A competitive response to a recent move from a bigger company in the same lane.
Two of those three are interesting to investors. The third is interesting to me as an engineer because it's usually visible 10 days before the move shows up on Hacker News.
Pattern 4 — the documentation sprint
Engineers don't write docs voluntarily. So when a team's commit log suddenly shifts from feature work to docs — README rewrites, API references, architecture diagrams, contributing guides — somebody asked them to. The somebody is usually one of three people: a fundraise lead doing diligence prep, a head of community preparing for an OSS launch, or a new VP Engineering doing onboarding for a hiring class.
All three are interesting. The pattern that's most uniquely a fundraise tell is the sequence: a sprint of feature commits, then a hard pivot to docs, then a return to features two weeks later. That mid-cycle docs sprint is the diligence prep. The team is making sure the codebase reads cleanly when an investor's analyst opens it for the first time.
Pattern 5 — the velocity regime change
The strongest signal is also the simplest. Compute commit velocity across a 14-day rolling window. Compare it to the org's six-month average. If the current window is more than 2× the average and the next two windows hold above 1.8×, the team has changed regimes. They aren't shipping faster because they're motivated this week — they're shipping faster because something organizational changed underneath them.
Velocity regime changes correlate with rounds more cleanly than any other single metric I've measured. The lead time is roughly 3 weeks before the announcement. The hit rate, on its own, is around 35% — meaning two-thirds of regime changes don't lead to a round. Some are pivots. Some are post-pivot recoveries. Some are just one engineer who got really excited.
But when a regime change overlaps with a contributor step function, the hit rate jumps to ~70% in my backtest across Q3-Q4 2025. That's the combination I act on.
The part I got wrong
For the first three months I weighted commit count more heavily than commit velocity change. I assumed high-volume orgs were higher-quality leads. They weren't. They were just bigger.
The correction was switching to z-scores within sector. A 200-commit week from a 5-person devtools company is a regime change. A 200-commit week from a 50-person AI infrastructure company is Tuesday. Once I started ranking by (velocity - 6mo_mean) / 6mo_stddev, the noise dropped and the small-team signals rose to the top. The orgs that ended up raising weren't the loudest — they were the ones whose own quiet baseline broke first.
What I actually do every Monday
The workflow is the same every week, no matter what the data shows:
- Pull the latest 14 days of
PushEvents for every org on the watchlist (~4,200 right now). - Compute the five patterns above for each org.
- Filter to orgs with two or more patterns firing simultaneously.
- For each survivor, open the GitHub org page and skim the last week of commits. If the commits look like real product work — not just bumping versions — the org goes on the call list.
- The call list goes into a doc with a one-line note per company. Some weeks the list is 4 long. Some weeks it's 30.
I don't act on single-pattern firings anymore. Not since the day I almost emailed an investor friend about a fintech that turned out to be running a hackathon. The signal was loud. The signal was wrong. The fix wasn't a better signal — it was forcing two of them to agree before I trusted any of them.
Originally published at signals.gitdealflow.com. The weekly Signal Report is free — no paywall, no account.
