A vendor pitched us a migration service. The sales deck had a screenshot of their GitHub: green contribution graph, recent commit badges, "actively developed" in bold. The CTO was sold before the technical evaluation started.
I asked for the repo URL. I ran two commands. I brought the numbers to the evaluation, and the "actively developed" claim became a specific, defensible question instead of a vibe.
The two commands
git clone --depth 500 vendor-service /tmp/vendor
npx @wuchunjie/gitpulse /tmp/vendor
The contribution-graph screenshot in the deck showed a busy 2025. The pulse showed:
Total commits: 428
Contributors: 3
Active days: 9 (last 90 days)
Files touched: 156
Top Contributors
d. vendor ############################ 389
support-bot #### 24
cto ## 15
Recent Activity
2026-09-01 ## 2
2026-07-14 ### 3
2026-05-02 #### 4
...
What the numbers said that the deck didn't
1. "Actively developed" was a 2025 phenomenon. 9 active days in the last 90, in three bursts of 2-4 commits. The busy green square in the deck was real — it was just last year. The current tense of the repo is "occasional bursts," not "active."
2. The "team" was a person and a bot. 389 of 428 commits from one name. The second contributor was support-bot — automated changelog or issue-triage commits, not a human. The third was the CTO, 15 commits total. The "engineering team" behind the service was, by the repo's own evidence, one person with a bot assistant.
3. The burst pattern matched the sales cycle. The three recent bursts (May, July, September) lined up suspiciously well with their release announcements. Bursts at announcement time are marketing, not maintenance. Steady activity between announcements is the maintenance signal, and there wasn't any.
What happened in the evaluation
I didn't say "the vendor is lying." I said the repo's maintenance cadence — 9 active days per quarter, one primary contributor — and asked the vendor to explain the gap between that cadence and their SLA. The answer was reasonable in isolation (the core service is stable, few changes needed) but it changed the risk calculation:
- Stability isn't maintenance. A service that needs few changes can still need response — to security findings, to platform changes, to the bug your integration hits. A one-person cadence of 2-4 commits per quarter means that response is a personal favor, not an SLA.
- The bot was doing the "active" part of the activity. Once you subtract the automated commits, the human cadence was ~6 commits in 90 days. That number is what you're actually depending on.
We still used the vendor — the product was good and the pricing was right — but the contract changed. We got the maintenance cadence in writing, a named second engineer with repo access, and an exit-assist clause (source escrow) that wasn't in the first draft. All three changes were because the numbers were in the room instead of a screenshot.
The general lesson
Vendor claims about their own code are marketing. Their repo is evidence. The two-minute check doesn't prove the vendor is bad — in this case it didn't, the product was solid — but it replaces the deck's adjectives with the repo's nouns: active days, contributor count, burst pattern.
And it does so before you've signed anything. After you've signed, those same numbers are just "historical context." Before, they're bargaining chips.
The tool is gitpulse: zero dependencies, local analysis of a shallow clone, nothing uploaded. Two minutes, one command, and the "actively developed" in the deck becomes a number you can put in the evaluation doc.
git clone --depth 500 <vendor-repo> /tmp/vendor && npx @wuchunjie/gitpulse /tmp/vendor
More Tools
| Tool | What it does | Command |
|---|---|---|
| scaffoldx-cli | Production-ready project templates in seconds | npx scaffoldx-cli |
| dotguard | Scan .env files for exposed secrets | npx @wuchunjie/dotguard |
| gitpulse | Git repo analytics in your terminal | npx @wuchunjie/gitpulse |
| snippetx | Terminal code snippet manager | npx @wuchunjie/snippetx |
If these save you time, consider buying me a coffee. All tools are MIT-licensed, zero-dependency, and run fully offline.
Top comments (0)