Playbook · operator how-to
How to qualify a 200-star repo in under 15 minutes
A repeatable 15-minute qualification rubric for the awkward middle — repos with 100–500 stars where you can't tell if it's a real company in the making or a side project.
The hardest repos to qualify are not the 50-star ones (clearly too early) or the 5000-star ones (well-known, fully-priced). It's the 200–500 star band — repos that have just enough heat to look interesting but not enough public information for you to commit to a meeting.
This playbook gives you eight checkboxes that you can run through in 15 minutes. Three or fewer = pass on it. Four to five = put on the watchlist. Six or more = book a 20-min intro call.
The checkboxes are intentionally observable from the public repo — no scraping, no API key, no email warm-up. The point is to get to a yes/no/watch decision without burning operator time.
Before you start
Prerequisites
- · A repo URL in the 100–500 star band
- · 5 min of focus per checkbox
Tools
- · GitHub web UI
- · GitDealFlow Scout Receipts (optional, free)
Steps
- 01
README check 1 — does it open with a problem statement?
2mOpen the README. The first 200 words should describe a real problem. If the first 200 words are a feature list or installation instructions, that's a 'tool for itself' signal, not a company. Check or unchecked.
- 02
README check 2 — is there a named target user?
2mScan for phrases like 'for engineers who...', 'for teams that...', 'for solo founders...'. A repo with no named user is selling to no one. Check if present.
- 03
README check 3 — is there a paid offering or self-host distinction?
2mLook for a 'pricing' link, a 'cloud version' section, or a self-host vs hosted distinction. Either signals business intent. Check if present.
- 04
Contributor check 1 — three or more committers in last 30 days
2mOpen Insights → Contributors, 4-week window. Count distinct names with non-trivial commits. Check if ≥ 3.
- 05
Contributor check 2 — top contributor has a public profile beyond GitHub
2mClick the top contributor's profile. They should have a non-empty website / Twitter / LinkedIn. Anonymous top contributor on a 200-star repo is a yellow flag (sometimes intentional, often not). Check if linked.
- 06
Contributor check 3 — contributor list is geographically dispersed
1mQuick scan of contributor avatars and profile locations — more than one country represented is a small but meaningful network-effect signal. Check if yes.
- 07
Issue check 1 — external issues outnumber maintainer self-issues
2mIssues tab → sort by recently updated → scan the top 20. If the maintainer is opening more than half of them themselves, the project is still inward-facing. Check if external > internal.
- 08
Issue check 2 — median-time-to-first-response under 72 hours
2mPick 5 recent external issues. Look at the time between opening and the first maintainer reply. If the median is under 72 hours, the maintainer is treating it like a product. Check if median < 72h.
Run the play
Run the auto-graded version →Frequently asked questions
Can I run this rubric on a 1000-star repo too?
Yes — and you should — but the value-add over a basic 'this is popular' read is much smaller. The rubric pays for itself the most in the 100–500 band where popularity hasn't done your job for you.
What if the README is in a non-English language?
Translate it (Google Translate or your browser). The three README checks are content checks, not language checks. The contributor and issue checks don't depend on language at all.
Is six checkboxes really enough to book a call?
It's enough to spend 20 minutes on a discovery call. It's not enough to write a check. Treat this as a pipeline-building rubric, not a diligence rubric.