What a technical review asks for, and how to answer instead of just listing

A technical review asks for evidence under seven headings, and the way you answer decides whether the reviewer spends the week reading or spends it asking. The headings, from Matt Van Itallie's checklist published in TechCrunch on 26 October 2022, are product roadmap, code quality, intellectual property, security, development process, engineering team contributions and DevOps [1]. The investor's version of the list is our technical due diligence questionnaire; this page is what to do when that list lands in your inbox.

The rule that runs through every heading is this: artefact first, sentence second. A reviewer who is handed a folder of real documents reads them, forms a view, and asks a small number of sharp questions. A reviewer who is handed a slide deck has to reconstruct the documents by asking, and every question they have to ask is a point at which your answer can differ from what they later find. Reveneau's own preparation method for a company facing review starts by converting the investor's list into a spreadsheet with one row per item and three columns: the artefact, the sentence, and the owner, because the spreadsheet makes it impossible to hand over a sentence with no artefact behind it without noticing.

What are the eight questions behind the list?

The reviewer has a list of documents to collect and a shorter list of questions to answer, and the second list explains the first. Van Itallie published the eight questions the day before the checklist, on 25 October 2022 [2]:

1. What have you been working on?
2. How much unit testing does your codebase have?
3. Does your security program match your company's maturity?
4. Are your subject matter experts in the building?
5. Do you know what third-party code you are using?
6. Can you explain the observed variation across codebases?
7. How much does finance invest in tech debt prevention?
8. Are you ready to learn and grow?

Read the checklist through these questions and it stops looking like paperwork. The twelve months of ticket data under the product roadmap heading answers question one. The testing evidence under code quality answers question two. The list of current and former developers answers question four. The eighth question has no document behind it; it is answered by how you respond when the reviewer finds something you did not know about.

What does the product roadmap heading ask for?

The product roadmap heading asks for proof that the team works on what the company says matters. The checklist lists five items: the process for collecting user and customer feedback, a sample of that feedback, the synthesised results, the last twelve months of product management data (Jira tickets, for example) comparing new-feature work with maintenance, and the roadmap for the next twelve months [1].

Artefacts: the ticket export for twelve months with a label per ticket (feature, maintenance, incident), the computed split, a sample of raw customer feedback, and the roadmap document. Sentence: "Over the last twelve months, X percent of engineering tickets were new features and Y percent were maintenance; the roadmap for the next twelve months is attached and the three largest items are A, B and C." The roadmap gets its own page in this guide, a technical roadmap for a fundraise, because it is the document the investor reads most closely.

If you have no ticket system, export whatever you have (pull request titles work) and label it by hand. Do not describe a process you plan to adopt.

What does the code quality heading ask for?

The code quality heading asks how the codebase is kept in a state a team can build on. The checklist lists seven items: what finance invests in preventing and fixing technical debt, security risk and IP risk; which languages are used and how a new one is adopted; refactoring needs; the breadth of testing (unit, automated, manual QA, user acceptance) with recent results; whether a line-level scanning tool such as SonarQube is deployed, with sample reports; how third-party code is managed; and an architecture description with diagrams [1].

Artefacts: the test run from the last main-branch build with its coverage report, the last static analysis report, the language list from the repository, the dependency manifest, and the three architecture diagrams described on presenting your architecture to investors. Sentence: "The suite runs on every pull request, takes N minutes, and the last run on main is attached; the parts of the system with no automated tests are X and Y, and here is why."

The sentence about the untested parts matters more than the coverage number. Question six on the reviewer's list is whether you can explain the variation across your codebases [2]. A company that says "the reporting module has no tests because it is being replaced in Q1, and the replacement is spec'd with tests first" has answered the question. A company that says "coverage is 71 percent" has invited the reviewer to find out where the other 29 percent is.

What do the intellectual property and security headings ask for?

The IP heading asks whether you own what you are selling, and the security heading asks whether you can keep it. IP items on the checklist: an overview of the company's IP and its key assets, an IP litigation search, evidence of domain ownership, software escrow status, inbound and outbound licences, how third-party code with copyleft or limited copyleft licences is handled, IP assignment and confidentiality agreements for employees and vendors, backup frequency, and written disaster recovery plans [1].

Artefacts: a dependency inventory with the licence of each entry, the signed assignment agreements (or a list of every contributor with the date each signed), the domain registrar record, the backup schedule and the last restore test. The inventory is the one most often missing. Morgan Lewis's June 2026 note on open-source diligence lists whether the company monitors and tracks its open-source usage and whether it runs regular scans as two of its six areas of inquiry [6]. Our engineering data room page gives the folder for these.

Security items: any IT shutdown or material malware or ransomware incident within the past three years, security scan reports, how access to the code repository is authenticated, recent penetration tests and audits, standards such as SOC 2, what customer information is accessed, a lawyer's assessment of GDPR and CCPA compliance, and PCI handling where cards are involved [1].

Artefacts: the incident log for three years (an empty log with a note saying how incidents are recorded is a valid artefact), the last scan report, the repository's access policy with multi-factor authentication shown enabled, the last penetration test report with its remediation status. Sentence: "We have had N incidents in three years, listed with root cause and fix; the last penetration test was on DATE, found N findings, and N remain open with owners and dates."

What do the process, team and DevOps headings ask for?

The last three headings ask how the code gets written, by whom, and on what. Development process items: the number of version control systems, development activity by repository over the last twelve months, and whether developers are coached on files per commit, adding unit tests and putting ticket numbers in commit messages [1]. The reviewer reads the commit history for all of this, so the artefact is repository access and the sentence is short.

Engineering team items: a list of current and former developers, which of them are the most important to the codebase (including contractors), and how you would manage if the key ones left [1]. This is where single-person risk is found, and it is the finding most likely to reach the first page of the report. Artefacts: the contributor list from the repository with join and leave dates, and a table mapping each core system to the two people who can change it. If any row has one name, that is a disclosure, and the sentence is the plan to make it two.

DevOps items: licence compliance for purchased software, the list of engineering tools, a description of the infrastructure with the IT budget, the split between on-premises and cloud, and planned improvements with their cost [1]. Artefacts: the last three cloud invoices, the tool list with seat counts, and the infrastructure diagram. The reviewer will check the cloud bill in your model against the invoices, so make sure they agree before the folder goes out.

How should you answer when there is no artefact?

Say "none", give a date, and stop. A reviewer expects gaps at every stage below a late-stage growth round, and a list of the gaps is itself an artefact: it tells them you have run the review on yourself. What a reviewer does not expect, and what costs trust, is a paragraph describing a practice the company intends to adopt, written as if it existed.

The reasons are practical. The reviewer will interview engineers separately from the founders, and an engineer asked "how often do you run the penetration test?" will answer honestly. If the data room said "annual penetration testing" and the engineer says "we have never had one", the finding is about the data room, and the reviewer will re-read every other sentence in it with that in mind. The investor-side page on technical due diligence red flags lists the gaps between account and system as the finding reviewers weigh most.

There is a second reason. The eighth question, whether the leadership is ready to learn and grow [2], is answered by how you handle the gaps. A founder who opens the review with "here are the eleven items we do not have, and here is the date for each" has answered it before the reviewer asked.

What does a finished answer set look like?

A finished answer set is one spreadsheet and one folder. The spreadsheet has a row per checklist item, with the artefact's file name, the one-sentence answer, the owner, and a status of "attached", "none, due DATE" or "not applicable, because". The folder has the artefacts, one sub-folder per heading, with a one-page index at the top that summarises the status column.

Send both together. Then do the thing that shortens every review: answer each follow-up request the same day, with an artefact, and add it to the folder so the reviewer never has to ask twice. The two-week checklist schedules the work of building the spreadsheet and the folder, and the pillar page on preparing for technical due diligence puts this page in the context of the whole preparation.