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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.