How to Do Technical Due Diligence on a Startup

Technical due diligence answers the question every investor faces but few know how to check: is the technology real, is the team capable, and will it scale? This six-step method uses public GitHub evidence to answer those questions before you sign.

What technical due diligence covers

Technical due diligence is the check on the engineering substance of a deal. It covers whether the product actually exists, whether the team can build and scale it, and whether the architecture will support the growth the pitch assumes.

You do not need to be an engineer to run a useful version of it. You need to know what evidence to ask for and how to read the public record that either confirms or contradicts the founder's claims.

Step 1: Verify the product exists in code

The first check is the most basic: does the company's public GitHub footprint match the product the founder described? Look for the repositories behind the product, check their activity, and confirm the code is real, current, and coherent, not a demo built for the data room.

If the core product is private, ask for a walkthrough and treat the thin public footprint as a data limitation rather than a red flag.

Step 2: Read the velocity and contributor history

Pull 12 weeks of commit velocity and contributor growth. A rising trend with a growing team is the healthy pattern. A flat or falling trend, a single-bus-factor team, or heavy contractor churn are all things to probe with the founder.

This is the quantitative core of technical DD: it converts the founder's claims about momentum and team into a verifiable time series.

Step 3: Assess engineering process

Read how the team works in public: how pull requests are reviewed, how issues are triaged, whether there are tests, and whether releases are disciplined. Sloppy public process is a leading indicator of sloppy private process.

Process matters because diligence is a prediction about the future: you are betting the team can keep shipping at scale, not just that they shipped once.

Step 4: Check for red flags

A short list of red flags to look for, none of them fatal alone but all of them worth a conversation:

• One founder accounting for nearly all commits, and no hiring despite claimed growth.
• A velocity spike in the weeks before the raise that does not match prior history.
• Repositories that were abandoned mid-feature, suggesting a pattern of not finishing.
• Public claims (team size, product scope) that do not match the public record.

None of these prove a bad investment, but each is a question the founder should be able to answer cleanly.

Step 5: Write it up

Technical DD only matters if it lands in the memo. Summarize the evidence in one page: what the footprint shows, the velocity and contributor trend, the process assessment, and the open questions. The GitHub Due Diligence Checklist is built for exactly this write-up, with 21 checks across four categories and a scoring rubric.

Start tracking for free →