Engineering Due Diligence for Angel Investors: A Practical Playbook
A hands-on guide for angel investors evaluating early-stage startups through public GitHub data. Learn what to check before writing a check, what patterns signal real traction, and what red flags to watch for.
Key Takeaway
Angel investors face a unique due diligence challenge: early-stage startups have limited data, no revenue history, and small teams. Public GitHub data fills this gap by revealing real engineering patterns before any metrics deck exists. This playbook covers the five-step diligence process: (1) velocity check — is the team shipping consistently? (2) team pattern check — does contributor composition match the founder's story? (3) tech stack evaluation — is the technology appropriate for the stage? (4) repository hygiene — does the codebase show sustainable practices? (5) red flag scan — signs that the engineering story does not add up. Each step takes 5-10 minutes and can be done from public GitHub data alone.
Angel investing is a conviction game. Most of the time, you are writing a check based on a founder's story, a prototype, and a market thesis. There is rarely enough data for traditional due diligence.
Public GitHub data changes that equation. It gives you a window into the engineering reality behind the pitch — without needing access to private repositories, confidential metrics, or technical consultants.
This playbook covers a five-step due diligence process that takes 15-30 minutes and requires nothing more than a web browser and the startup's GitHub organization URL.
Step 1: Velocity Check (5 minutes)
Open the startup's main public repository and look at the commit graph. The question is not how many commits there are, but whether the pattern is consistent.
Healthy early-stage teams ship most days. They may have a lighter day here and there, but the commit graph shows color on most weekdays. Red flags include: - Weeks of silence followed by a burst of commits (suggests part-time work or desperation shipping) - Commits clustered on a single day of the week (suggests the founder is squeezing work in around a day job) - No commit activity in the last 30 days (the team may be stalled, pivoting, or losing momentum)
For a deeper dive on interpreting velocity patterns, see our guide on commit velocity explained.
Step 2: Team Pattern Check (5 minutes)
Review the repository's contributor list. Compare what you see to what the founder told you about team composition.
A company claiming 10 full-time engineers but showing only 2-3 GitHub contributors is not necessarily lying — many startups keep their core product code in private repositories. But it is worth asking: who is doing the public work, and does the private code activity align with the overall team story?
Look for contributors who appear to be co-founders (early joiners with consistent contribution patterns) versus recent hires (new contributors appearing in the last 30-60 days). A sudden jump from 2 to 5 contributors in two weeks is a classic post-fundraise hiring signal — and the topic of our deep dive on 5 GitHub patterns that predict fundraises.
Step 3: Tech Stack Evaluation (5 minutes)
Check the languages and frameworks shown in the repositories. GitHub surfaces this prominently on each repository page.
The question is fit: is the technology appropriate for the startup's stage and product? A pre-seed startup with Kubernetes, Terraform, and a full observability stack may be spending time on infrastructure that should go into product. A seed-stage company still using a prototype framework with no testing infrastructure may have hidden technical debt.
This is contextual judgment, not rules. Some products genuinely need complex infrastructure from day one. But the tech stack tells you something about the founder's engineering philosophy — and whether their stated priorities match their actual behavior.
Step 4: Repository Hygiene (5 minutes)
Scan the last 20-30 commit messages in the main repository. They tell you what the team is actually doing.
Good commit messages describe specific work: "Add payment webhook retry logic," "Fix pagination bug on search results," "Refactor auth middleware." These show disciplined engineering practices.
Red flags include: commits that are all automated (bot dependency updates, auto-formatting), commits described by single words ("fix," "update," "wip"), or commit history dominated by documentation, configuration, and build tooling changes rather than product code.
Step 5: Red Flag Scan (5 minutes)
Finally, scan for warning signs that warrant a deeper conversation with the founder:
- **Inconsistent narrative**: The founder describes a product that does not match the repositories, languages, or frameworks visible on GitHub. - **Activity without substance**: High commit velocity that is dominated by auto-generated commits, dependency bumps, or documentation changes rather than product code. This is covered in detail in our post on investor mistakes when reading GitHub signals. - **Disappearing contributors**: A contributor who was highly active suddenly vanishes. Could be a co-founder departure you have not been told about. - **Contradictory stage signals**: The GitHub profile suggests a different stage than the founder claims. A startup with 3 contributors and 50 commits total may be pre-seed, not Series A.
These five steps do not replace a proper technical deep dive with the engineering team. But they do help you decide which startups deserve that deep dive — and which ones have a story that does not hold up to the data.
For the complete set of engineering metrics every investor should track, see our 7 metrics checklist. To see which startups are passing these checks right now, browse the sector rankings.