How to Evaluate GitHub Activity for Startup Scouting: A Practical Checklist

Public repository activity can be inspected without asking the founder, and is granular enough to compare one window against another. It is also easy to misread. A commit spike can be a product push, a hackathon, or a documentation cleanup, and raw counts punish teams for merge habits. This is a working checklist for evaluating one startup's GitHub activity in a single sitting: what to open, what each view can and cannot tell you, and which cautions separate signal from noise.

One scope note first: everything here reads public data only. The GitDealFlow methodology page states that its pipeline uses the public GitHub REST API, excludes bot commits, and touches no private repositories and no scraping. Hold the same line manually: it keeps your evidence reproducible.

Start with the repository Pulse summary#

GitHub's Pulse view lives under the Insights tab and summarizes what happened: merged and open pull requests, new and closed issues, and the people involved. Two habits make it useful:

1. Change the period. The dropdown defaults to the last seven days, too short to judge a startup; set a longer window, then compare two equal windows.
2. Use Pulse as the sanity check on any spike: a jump that shows up as many merged pull requests reads very differently from a few giant automated syncs.

Read the contributors graph correctly#

The contributors graph, also under Insights, answers who did the work, over what period. GitHub's docs document the caution that matters most: the graph counts default-branch commits. Commits that only live on feature branches do not appear until merged; GitHub's docs use `gh-pages` as the example. Treat what it shows as contributor identities, not employees: teams that keep work on long-lived side branches will look smaller, and neither the graph nor the pull request queue is a headcount.

Pull commit velocity from the REST API#

For numbers you can log and compare week over week, pull weekly commit counts from the repository statistics endpoint. Summed into 14-day buckets they approximate the methodology's rolling 14-day commit velocity; weekly buckets have fixed boundaries, so treat the sum as a boundary approximation of a rolling window, not an exact reading. Two cautions:

1. Send the `X-GitHub-Api-Version` header on every call, as the API versioning guide recommends, so your numbers keep one meaning across API versions.
2. Keep the set of repositories you measure fixed across windows. Switching repos mid-trend changes what is being measured, and the trend line breaks.

Squash merging turns a whole pull request into one commit: identical work, very different counts. Commit velocity explained covers the rest.

Normalize before you compare, then demand persistence#

Per the methodology, the signal is a "percentage change in 14-day commit velocity vs. the prior 14-day window, normalized against each org's own baseline so it works across stages and team sizes." In practice: compare an org to its own past, rather than treating another org's raw count as equivalent.

Then apply the persistence rule, also from the methodology: "A breakout must persist into a second 14-day window before it becomes actionable." Hackathons and release weeks produce single-window spikes; require persistence into a second window before treating a change as real.

Red flags checklist#

Activity concentrated in a mirror, template, or tutorial repo.

Contributor identities shrinking while commit count rises. That can have several explanations; it is not a headcount, so verify separately.

Repositories freshly re-created with shallow history, which makes trend lines unreadable.

Switching which repository you measure mid-trend, which resets the comparison.

The one-sitting evaluation, step by step#

1. Open the organization and confirm it is the company you think it is, not a namesake or fan fork.
2. Open Pulse, set a longer period, and compare two equal-length windows.
3. Open the contributors graph, remember the default-branch caveat, and compare distinct pull request author identities with graph entries; both are identities, not headcount.
4. Pull weekly commit counts from the statistics endpoint and compute two consecutive 14-day bucket sums versus the prior two, treating them as boundary approximations.
5. Confirm the organization's main product repository is what you measured, not a mirror, template, or fan fork.
6. Check merge habits: if pull requests squash into one commit, read pull request trends alongside commits.
7. Require persistence into a second window before the org earns a watchlist entry.
8. Log the windows, the numbers, and the caveats. Treat the result as a lead to verify, never a verdict.

For where this step sits in a full scouting process, see the pre-seed scouting guide and the data sources page.