# The Public-Repo Technical Diligence Read for Early-Stage Deals

*You can produce a go/flag/stop technical read of a startup from public repositories alone in under a day, with named red flags and the evidence behind each.*

- Canonical URL: https://www.refolk.ai/guides/public-repo-technical-diligence-read
- Pillar: Investing and deal sourcing
- Format: Playbook
- Published: 2026-08-06
- Last reviewed: 2026-08-06
- Reading time: 14 min

A technical deal just landed and there is no data room yet. This guide is the ordered process an associate keeps open to read a startup's public code as a pre-term-sheet risk signal, and to turn that read into a go/flag/stop verdict with named red flags and the evidence behind each. It is for early-stage investors, platform and talent partners at funds, and angels who need a defensible technical read before they commit partner time or a term sheet.

The existing "review the GitHub" line on every checklist is not a method. This is: concrete thresholds, a legal boundary, and base rates so you know when a red flag is common noise versus a genuine outlier.

## Why a same-day public-repo read is the right scope

The technical read is time-boxed to under two weeks, so a repeatable checklist beats depth. Full VC diligence runs roughly 2 to 6 weeks by stage, with seed rounds averaging 2 to 3 weeks and Series A and beyond 4 to 6 weeks. But the technical workstream is only a slice of that window, which means you rarely get more than two weeks of an auditor's attention, and often far less at seed.

That compression is why a public-repo pass matters. It is the one read you can finish in a day, before you have data-room access, that flags risk early enough to change how you spend partner time. The advice that technical review only matters at later rounds is outdated: rounds got more competitive so funds diligence harder, and AI-assisted development made codebases faster to produce and harder to trust. When the code itself stops being evidence of engineering discipline, you need a process that reads the signals around the code, not just the code.

**2 weeks - The most auditor attention you typically get**

The technical read is a slice of a 2 to 6 week window, so a same-day pass is the only read that reliably fits a pre-term-sheet decision.

The scope of this guide is deliberately narrow. It grades what public repositories, contributor graphs, dependency manifests, and public hiring signals can tell you. It does not replace a full code audit under NDA, and it does not read private IP. It tells you whether to spend partner time getting to that deeper read at all.

## The five signals that carry the verdict

Five signals do most of the work: authorship concentration, license risk, dependency health, secret exposure, and whether AI claims survive contact with the repo. Everything else is context.

Each of these has a documented base rate, which is what stops you from over-reacting. A red flag that appears in most codebases is a cost of doing business, not an outlier. A red flag that is rare is a genuine signal. Table A is your denominator: the "how common is this" number behind each flag, from an audit of 965 commercial codebases.

| Signal | Prevalence |
|---|---|
| License conflict present | 56% |
| No or custom license | 33% |
| Any OSS vulnerability | 86% |
| High or critical vulnerability | 81% |
| Components over four years out of date | 90% |

Read that table before you panic at any single finding. If 86% of audited codebases contain an open-source vulnerability and 90% carry components more than four years out of date, then finding one in your target is baseline, not a stop. What moves the verdict is the combination: an out-of-date, vulnerable dependency that also carries a copyleft license and sits on the core value path.

Here is how each signal proves something, and what it looks like when it lies:

- **Authorship concentration.** Proves whether knowledge is distributed or trapped in one person. It lies when a large headcount hides concentrated per-file ownership.
- **License class.** Proves whether the company can legally ship and be acquired. It lies when the manifest looks clean but vendored or AI-generated code carries no license.
- **Dependency health.** Proves whether the stack is maintained. It lies when the top-level manifest is tidy but transitive dependencies are stale.
- **Secret exposure.** Proves operational discipline, and it is binary. It lies when HEAD is clean but a live key sits in history.
- **AI claim fidelity.** Proves whether the product is what the deck says. It lies when a wrapper reads as a proprietary model.

> **Rule:** Base rate before verdict
>
> Never flag a signal without checking its prevalence first. A finding that appears in most commercial codebases is a cost line, not a stop. The verdict comes from the combination of a common flaw and a load-bearing location.

## The legal line: what reading public repos permits

Reading public repositories by hand for diligence is permitted; the boundary is spam and resale, not research. GitHub's Acceptable Use Policy explicitly allows research use of public, non-personal information. A single investor reading a handful of repos and profiles by hand is far under any rate limit.

The hard line is unambiguous: you may not use information from the Service for spamming purposes, including sending unsolicited emails or selling personal information, such as to recruiters, headhunters, and job boards. Diligence is a read, not a send, so you stay inside the line as long as you do not turn contributor lists into an outbound list.

On throughput: the primary rate limit for unauthenticated requests is 60 requests per hour, while authenticated requests count toward a personal limit of 5,000 requests per hour. Generating a personal access token before you start is the difference between a read that stalls and one that finishes in an afternoon. This is why authentication is its own step in the procedure below rather than an afterthought.

#### The seven-step public read

1. **Scope** - Map the org, founder accounts, repos, stars, and last-push dates
2. **Authenticate** - Token for 5,000 requests/hour instead of 60
3. **Authorship** - Compute bus factor from per-file ownership
4. **Deps and license** - Map SPDX classes, flag copyleft and no-license
5. **Secrets** - Scan full history, confirm push protection
6. **AI claims** - Supported, wrapper, or unsupported, claim by claim
7. **Grade** - Go, flag, or stop with evidence per flag

*Each stage produces a named artifact, and the last one is a memo a partner reads in five minutes.*

## Run the read: the ordered procedure

Work the steps in order; each produces a named artifact, and the final memo is just the assembly of the six that precede it. At seed, steps 3 through 6 often collapse into a single technical-advisor session, because the read is a conversation rather than a structured multi-area review. At Series A and beyond, run them as separate passes.

#### The public-repo technical read

1. **Scope and inventory the footprint** - Find the company's GitHub org and the founders' personal accounts, then list public repos, stars, languages, and last-push dates. Done means a one-page repo map with owners identified, produced before any data-room access.
2. **Authenticate your tooling** - Generate a personal access token so calls count toward the 5,000 requests/hour limit rather than the 60/hour unauthenticated cap. Done means calls return without a 403.
3. **Read activity and authorship** - Pull commit history, the contributor list, and commit cadence, then compute bus factor from per-file authorship share. Done means you know the truck-factor developers and whether commits are steady or a single pre-raise dump.
4. **Scan dependencies and licenses** - Read the manifests, map each license to its SPDX class, and flag GPL/AGPL copyleft, no-license, and custom-license components. Done means a license risk list that names the transitive and vendored layers.
5. **Check secret and security hygiene** - Scan the full git history for exposed keys, and confirm secret-scanning push protection and Dependabot are on. Done means zero live secrets confirmed, or a documented exposure with commit and rotation status.
6. **Verify the AI claims** - Cross-check every AI claim in the deck against repo evidence, job postings, and docs. Done means a claim-by-claim table marking each supported, wrapper, or unsupported.
7. **Grade and write the memo** - Convert the findings into a go/flag/stop verdict with the evidence attached to each flag. Done means a one-page memo a partner can read in five minutes.

### On thresholds, stated as this guide's convention

No single published standard fixes numeric thresholds for investors, so the thresholds below are this guide's own convention. State them that way in your memo so a second reviewer knows where judgment enters.

- **Bus factor of 1 alone: not a stop.** It is a flag only when combined with no documentation and no tests.
- **Any live secret in git history: hard stop.** Binary and objective.
- **Copyleft (GPL/AGPL) on the core value path: flag, escalate to counsel.** Permissive (MIT/Apache) is a note, not a flag.
- **No-license or custom-license core code: flag.** The company cannot cleanly grant rights it does not hold.
- **Single pre-raise commit dump: flag.** It undermines every claim about steady engineering.

## Checking AI claims: separating real work from wrappers

Cross-channel evidence, not code aesthetics, is what separates genuine AI engineering from AI-washing. Real AI adoption leaves consistent evidence across company messaging, job postings, technology footprint, announced partnerships, and governance disclosures. A wrapper leaves a thin, inconsistent trail.

Be honest about the limits here: no source gives a validated repo-only checklist that cleanly separates real from AI-washed code. The reliable signals are cross-channel. The clearest hiring tell is simple. Companies building real AI recruit ML engineers, data scientists, MLOps engineers, and AI researchers; if the careers page shows no AI-related hiring, the AI claims may be more marketing than engineering.

The wrapper pattern is well documented: adding "AI-powered" to a product that uses no AI, or wrapping a ChatGPT API call and calling it proprietary technology. In one diligence case, a portfolio company's "AI-driven risk engine" turned out to be manually maintained rules tables with a GPT chatbot bolted on that represented roughly 2% of functionality. The market has harder examples too: a company raised $42M claiming AI automation while secretly using human workers, and an "AI drive-thru" needed human intervention for 70% of orders.

Talent-supply ratios turn this into a checkable claim. Refolk's index gives you a hard denominator for how many people with a given skill exist in a market, so a headcount claim stops being unfalsifiable.

| Market | ML Engineers | Share vs US |
|---|---|---|
| United States | 10,699 | 100% |
| United Kingdom | 1,455 | 13.6% (derived) |
| US:UK ratio | - | 7.35x (derived) |

A UK seed startup claiming a large in-house ML team is drawing from a pool of 1,455, so its headcount claim is checkable against a hard denominator. If the deck says fifteen ML engineers in London, ask who they are and where they came from.

The second table separates deep model-building skills from wrapper skills in a single market, which is exactly the distinction the wrapper question turns on.

| Skill | US profiles | Share of PyTorch pool |
|---|---|---|
| PyTorch (model-building) | 65,975 | 100% |
| LangChain (LLM-wrapper) | 17,437 | 26.4% (derived) |
| PyTorch:LangChain ratio | - | 3.78x (derived) |

Use this as a market baseline. When a startup claims deep proprietary AI but its own footprint skews to LangChain-type wrapper skills with no model-building depth, the claim maps to the documented wrapper pattern. That is the moment to ask whether AI touches the core value path or a support corner.

I ran this search: `Machine learning engineers who worked at OpenAI, Anthropic, or DeepMind and are now at seed-stage startups` - [see the full result list](https://www.refolk.ai/s/t5gzanncgn).

*Returns named people with real model-building pedigree, so you can check whether an AI startup's team is who the deck says or a hiring gap dressed up as depth.*

The wrapper economy has a measurable footprint, and [Refolk](/) lets you check a team's real skill mix against these baselines in plain English rather than scraping profiles by hand. When the deck names a team, you can verify its ML pedigree in minutes and put the check in your memo as evidence, not impression.

> A clean manifest is exactly where AI-washed teams look safest and are not.

## How this read goes wrong: failure modes and false positives

The most valuable part of a diligence standard is knowing how it lies to you. Each failure mode below has a false positive to guard against and a concrete check that defeats it.

**Star-count halo.** High stars read as traction but can be bought or campaign-driven. Check star acquisition timing and whether stargazers are real, active accounts, not the code quality. A spike that lines up with a launch post is marketing, not adoption.

**Single pre-raise commit dump.** A repo that looks active may be one bulk commit before fundraising. The false positive is reading "steady cadence" from a recent last-push date. Check the distribution of commit timestamps, not just the most recent one.

**Bus factor misread.** A large team does not mean distributed knowledge. As the number of developers grows the relative bus factor decreases, and core knowledge stays concentrated in relatively few individuals. Compute per-file authorship share, not headcount. And remember the base rate: 46% of 133 popular projects had a truck factor of 1, so TF=1 is normal, not exceptional.

**License scan blind spot.** Manifest-only scans miss vendored code and AI-generated snippets. Only 77% of dependencies are identifiable via package manager scanning, so a "clean" manifest is a false negative waiting to happen. Check for copied source and the transitive layer, where 64% of components live and nearly half of high or critical vulnerabilities originate.

**Secrets in history, not HEAD.** A clean current tree can hide live keys in history. The false positive is "no secrets in the latest commit." Scan the full history. A deleted-then-rotated key is fine; a deleted-but-not-rotated key is a live breach.

**AI-wrapper masquerade.** A GPT chatbot bolted onto rules tables reads as an "AI product." Recall the 2% functionality case. Check whether AI touches the core value path or a support corner.

**Empty public footprint over-penalized.** Serious startups keep core IP private, so absence of public repos is not itself a stop. Do not grade the empty org. Check founders' personal accounts and prior work instead, and request read access under NDA.

**Recency without a threshold.** "Last commit" alone is ambiguous. Project death has no fixed time threshold, and a 26k-star repo can sit idle for years while its author stays active elsewhere. Cross-check author activity before flagging abandonment.

> **Watch out:** The most expensive false positive is a clean manifest
>
> Only 77% of dependencies are identifiable by package manager scanning, and the rest are introduced by other means, including AI coding assistants. A tidy package.json is exactly where an AI-washed team looks safest and is not. Always check vendored and transitive layers.

#### Verdict grid for a single flag

Horizontal axis runs from Common (high base rate) to Rare (low base rate). Vertical axis runs from Support corner to Core value path.

| Quadrant | What it means |
| --- | --- |
| Common and on core path | Flag and price it; expect remediation cost |
| Rare and on core path | Stop or escalate; this is a genuine outlier |
| Common and in a corner | Note it and move on |
| Rare and in a corner | Note with a watch item, no action now |

*A flag's weight depends on how common it is and whether it sits on the core value path.*

## Secret exposure: the one objective stop

Secret exposure is the one binary, high-consequence flag two reviewers will always score identically. A single live key in git history is an objective stop, no judgment required.

The scale explains why this is non-negotiable. GitHub detected more than 39 million leaked secrets in 2024, and credential-involved breaches cost an average of $4.88M per incident. Against those numbers, a startup that ships live keys in a public repo has demonstrated an operational failure that will recur under your money.

The mechanics matter. GitHub launched push protection in April 2022 and enabled it by default for all public repos by February 2024, so a team shipping secrets is now actively working around a default guardrail. Confirm push protection is on, then scan the full history yourself. The distinction that decides the verdict: a key that was committed, then rotated, is a hygiene note; a key still live in history is a breach you are being asked to fund.

```stat
number: 39M
label: Secrets GitHub detected as leaked in a single year
note: One live key in a target's git history is an objective stop, set against a $4.88M average credential-breach cost.

## Frequently asked questions

### How long should the technical read take before a term sheet?

Plan for one working day of associate time on the public read. Full VC diligence runs 2 to 6 weeks by stage, but the technical workstream is only a slice of that, and you rarely get more than two weeks of an auditor's attention. Because the window is short, a repeatable same-day public-repo pass beats a deep review you cannot finish, and it fits the pre-term-sheet decision cleanly.

### Is it legal to read a company's public repos this way?

Yes, for a hand read. GitHub's Acceptable Use Policy permits research use of public, non-personal data, and a single investor reading a handful of repos and profiles by hand is far under any rate limit. The hard line is spam and resale: you may not use the data to send unsolicited mail or sell personal information to recruiters, headhunters, or job boards. Authenticate to get 5,000 requests/hour instead of 60.

### Should an empty public GitHub org stop the deal?

No. Serious startups keep core IP private, so an absent public footprint is not itself a stop. Do not grade the empty org. Instead, pivot to the founders' personal accounts and prior work, and use the diligence window to request read access to a private repo under NDA. Over-penalizing an empty org is a documented false positive.

### How do I tell real AI from an AI wrapper using only public signals?

Real AI adoption leaves consistent cross-channel evidence: model-building dependencies, ML hiring, and docs that describe training and evaluation. A wrapper shows a bolted-on API call and no model-building depth. One documented case was an 'AI-driven risk engine' that was manually maintained rules tables with a GPT chatbot representing about 2% of functionality. Ask whether AI touches the core value path or a support corner, and check the team's skill footprint against market baselines.

### Is a bus factor of one a hard stop?

No, not on its own. A truck factor of 1 is normal at early stage: 46% of 133 popular GitHub projects had a truck factor of 1 (Avelino et al., 2016). Price it, do not fear it. The real flag is TF=1 combined with no documentation and no tests, which means the knowledge is concentrated and undocumented. Compute per-file authorship share rather than headcount, because core knowledge stays concentrated even on large teams.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/public-repo-technical-diligence-read*