What investors look for in a startup's codebase

Investors look for five things in a startup's codebase, and a reviewer can find all five without asking a single question, because each one is visible in the repository, the deployment log and the dependency manifest. This page describes what the reviewer sees, so that you can see it first. The investor-side method is on assessing code quality, and the pillar page on preparing for technical due diligence puts this page in sequence.

The five, in the order a reviewer usually reaches them:

1. Whether the tests would catch a broken change.
2. Whether more than one person can change each core system.
3. Whether the third-party code carries licences that permit the sale.
4. Whether changes reach production safely and often.
5. Whether the code matches the account the founders gave of it.

Reveneau's preparation work for a company facing a review begins with the same five, run against the repository before the investor's reviewer sees it, because every one of them produces a number or a table that the reviewer will otherwise produce for you.

Would the tests catch a broken change?

The reviewer's second question, in Matt Van Itallie's TechCrunch list of 25 October 2022, is "How much unit testing does your codebase have?", and the article's point is that the level should match the company's stage and industry [2]. A reviewer opens the test directory, runs the suite, and reads the last few runs on the main branch. They are looking for three things: that the suite exists and runs green, that it covers the parts of the system where a break would cost the most (billing, authentication, data export), and that it runs on every change rather than on request.

What they measure: coverage as a percentage, the time the suite takes, and which modules have no tests. What to prepare: the last main-branch run with its coverage report, and a short table of the modules with no coverage and why. "The reporting module has no tests because it is being replaced in Q1 and the replacement is specified with tests first" is an answer. "Coverage is 71 percent" is an invitation to look for the other 29.

If AI tools wrote a large share of the code, the reviewer's interest moves from coverage to evidence that each change was checked before it merged. Veracode's report of 30 July 2025, which tested more than 100 language models across Java, Python, C# and JavaScript, found that 45 percent of generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities, with Java at 72 percent [9]. A reviewer who has read that report wants the review trail and the test or evaluation run for each generated change, and our page on preparing an AI-written codebase for review covers what to show.

Can anyone other than the author change each core system?

Van Itallie's fourth question is "Are your subject matter experts in the building?" [2], and the reviewer answers it from the commit history. For each core system they list the people who have changed it in the last year and how many of them are still employed. A system whose only recent committer is one person is a single point of failure for the company, and it is the finding most likely to reach the first page of the report.

The investor-side page on assessing the engineering team describes how a reviewer maps knowledge to people. From your side, build the same map before they do: one row per core system, the two people who can change it, and the date each last did. Where a row has one name, that is the item to fix first, because it takes longest. Pairing, documentation and one deliberate handover project will move a second name onto the row in four to six weeks; nothing moves it there in two.

Contractors count, and former contractors count more. The checklist of 26 October 2022 asks for the most important developers "current, former, contractors" by name, and for the management strategy after key departures [1]. If a contractor who left last year wrote the payment integration, say so, name who has since changed it, and show the assignment agreement that puts the code in the company's ownership.

Does the third-party code let you sell the product?

The reviewer's fifth question is "Do you know what third-party code you are using?" [2], and the reviewer answers it by generating a dependency inventory from the manifest and reading the licence of each entry. The concern is copyleft. Morgan Lewis's note of 5 June 2026 on open-source diligence in M&A explains it: proprietary code packaged with copyleft code and shipped to customers may be required to be made public, "which would diminish the commercial value almost immediately" [6]. The same note lists six areas a buyer asks about, including whether the company keeps an open-source policy, whether it monitors and tracks its open-source usage, whether it runs regular scans, and whether it has an approval process for copyleft-licensed software.

What the reviewer measures: the count of dependencies by licence family, the count with no licence declared, and any copyleft entry in a component that is distributed rather than run as a service. What to prepare: the inventory, generated by a tool rather than by hand, with a column for how each copyleft entry is used. A dependency under a strong copyleft licence in a backend service you host is a different fact from the same dependency in a mobile application you distribute, and the inventory should say which.

Licence questions land hardest at a sale, and our page on preparing for a sale covers the inventory a buyer's counsel will expect. The investor-side detail is on open-source licence due diligence.

Do changes reach production safely and often?

A reviewer reads the deployment log and the incident log together, and the numbers they compute are DORA's software delivery metrics: change lead time (commit to running in production), deployment frequency, failed deployment recovery time, change fail rate (the share of deployments needing immediate intervention, such as a rollback or hotfix), and deployment rework rate [8]. DORA groups the first three as throughput and the last two as instability.

The reviewer is checking two things. First, that the numbers describe a team that can ship the roadmap in the time the plan allows. A team that deploys monthly cannot deliver a roadmap that assumes weekly releases. Second, that the numbers agree with the deck. "Continuous deployment" in a slide and a deploy log with eleven entries in a year is a gap between account and system, and gaps of that kind are what the investor-side page on technical due diligence red flags weighs most.

What to prepare: the five numbers for the last quarter, computed from the logs, with the logs in the data room. A dashboard is optional; what matters is being able to say "we deployed 34 times last quarter, median lead time two days, three rollbacks" without looking it up.

Does the code match what the founders said?

This is the check that runs through all the others, and it is the one Van Itallie's eighth question ("Are you ready to learn and grow?") is about [2]. The reviewer has the deck, the data room and the management meeting notes, and reads the repository against them. Every architectural claim, every process claim and every number in the deck is a sentence that can be true or false in the code.

Van Itallie's sixth question, "Can you explain the observed variation across codebases?" [2], is the same check applied to quality. Most companies have one well-kept repository and two neglected ones, and that is normal. What the reviewer wants is the reason: the neglected ones are being retired, or serve an internal tool, or are a prototype that never reached customers. A reason given before the reviewer asks is a sign of a team that knows its own system.

What to prepare: read the deck as the reviewer will, one claim at a time, and check each against the repository. Where a claim is ahead of the code, change the claim. Our page on presenting your architecture to investors covers the version of this for diagrams.

Which of the five should you fix first?

Fix single-person knowledge first, then licences, then tests, then delivery, then the deck. The order follows how long each takes and how much each costs in the report.

What the reviewer finds	How long to fix	Where it lands in the report
One person can change a core system	Four to six weeks of pairing and handover	First page, as key-person risk
Copyleft dependency in distributed code	Days to weeks, depending on the replacement	First page at a sale, a condition at a raise
Core module with no tests	One to three weeks per module	Body of the report, as a maintainability finding
Monthly deploys, high change fail rate	A quarter of process change	Body, as a delivery-capacity finding against the roadmap
Deck claims ahead of the code	One afternoon to rewrite the claims	First page if found by the reviewer, nowhere if fixed by you

The last row is the cheapest fix and the most expensive omission. Fix it the day you read this page. The investor-side page on assessing technical debt covers how a reviewer weighs the middle rows, and what a technical review asks for says how to hand each of these over once you have decided what to fix and what to disclose.

What a reviewer does with a good codebase

A reviewer who finds a green suite, two names on every core system, a clean licence inventory, a deploy log that matches the deck and a deck that matches the code writes a short report. Short reports close rounds. That is the whole reason to do this work months ahead rather than during the review, when the only lever left is disclosure.