Angel investor due diligence on technology: judging a startup's software

Angel investor due diligence on technology is the work of confirming that the software a startup says it has is real, runs for real users, can survive the founder being away for a month, and does what the pitch deck says it does. The published angel checklists do not cover it. This guide does, for a reader who does not write code.

Who this is for

You are an angel, a member of an angel group, or the lead on a syndicate. You have a deck, a founder you like, and a cheque size that does not justify hiring a firm to read the code. You want to know what you can check yourself, what you should ask someone else in the group to check, and when the honest answer is to pay for a review.

Most angel diligence guidance assumes the technology is somebody else's problem. The Angel Capital Association's best-practice guide on due diligence, written by David Eyler at Columbia University in July 2007, is organised into sections on defining risk, when to start, creating a plan, non-disclosure agreements, reasons deals are rejected, site visits and references, and how much analysis is appropriate. It discusses technology once, as a risk that "it won't work or, more likely, that it won't work in time to be relevant". There is no section on the product, the code, or the people who wrote it.

The UK Business Angels Association's 2020 guide to the due diligence process does have a Technical heading. It carries eight numbered questions. They ask whether the technology is stand-alone or dependent, whether it needs licensing, whether it is a platform, whether it can be protected by IP, whether it is incremental or disruptive, whether it is ready for market, who the large companies in the space are, and what the technology trends are. Every one of those is a question about positioning. None asks whether the software runs.

That gap is the reason this guide exists. What angel diligence misses on technology goes through both documents section by section.

The short version

• Angel diligence checklists cover management, market, financials, legal and deal terms. The ACA's 2007 guide has no technology section and the UKBAA's 2020 checklist has eight technical questions, all about positioning and IP.
• Hours spent on diligence are the one input with a measured link to angel returns: 5.9X above the 20-hour median against 1.1X below it, in Wiltbank and Boeker's November 2007 study of 539 group angels and 1,137 exits.
• A non-technical angel can run a one-hour technical check alone. Ask for a screen share of the product on a real customer account, look at the commit history, ask who else can deploy, and ask what the founder would rebuild.
• The three questions that decide most pre-seed and seed technical risk are: is this a demo or a production system, does the product depend on one person, and has the AI claim ever been tested.
• In an angel group, assign one member as the technical reviewer per deal, with a written scope, and let a non-technical lead own the decision.
• Pay a firm when the cheque or the round is large enough that a wrong technical answer costs more than the review. Vendor-stated prices for a scoped software review run from $5,000 at the low end (MEV) to $95,000 at specialist firms (Papermark's 2026 survey).
• Reveneau offers that review, and the whole method for a larger deal is in the technical due diligence guide.

Why the hours matter, and what the study cannot tell you

The only published measurement of angel diligence against angel returns is Wiltbank and Boeker's "Returns to Angel Investors in Groups", published in November 2007 by the Angel Capital Education Foundation with support from the Kauffman Foundation. It surveyed 539 angels in 86 groups, who reported 1,137 exits. The overall multiple was 2.6X in 3.5 years. Fifty-two percent of exits returned less than the money invested. Seven percent returned more than 10X and produced 75 percent of all the money returned.

On diligence, the study asked each angel how many hours they spent before each investment. The median was 20 hours and the mean was 60. Angels above the median saw an overall multiple of 5.9X; angels below it saw 1.1X. Sixty-five percent of the below-median exits returned less than 1X, against 45 percent above the median. The top quartile, angels who spent more than 40 hours, saw 7.1X.

Three limits are in the report itself, and they matter for how you use it. The hours were self-reported, from memory, about investments that had already exited. The study does not split hours by type, so it cannot say whether the technical hours, the reference-check hours, or the market hours carried the effect. And the data is from 2007, with 62 percent of the exits after 2004. The authors say directly that "length of time may not be the only important factor" and that future research should look at the quality of diligence rather than the quantity alone. Why the hours you spend on diligence matter covers the study and its limits in full.

What the study does support is a modest claim: angels who do more checking do better, and the median angel does 20 hours. This guide is built for one of those hours to be spent on the software.

How the technical check works, step by step

Reveneau's angel review starts with a screen share of the product on a real customer account rather than the founder's demo account, because the gap between a demo and a production system is the single most common technical finding at pre-seed and seed. The rest of the method follows from that.

1. Ask for the product on a real account, live. A demo account is prepared. A real customer account has the state a real customer left behind. Ask the founder to log in as a customer, with the customer's permission, and to do the thing the deck says customers do. Watch where they hesitate. Demo versus production lists the tells.
2. Ask to see the commit history. Every codebase kept in version control has a log of who changed what and when. You do not need to read the code to read the log. Ask the founder to open it and scroll back three months. You are looking for how many names appear, whether the changes are steady or come in bursts before investor meetings, and whether the most recent change was this week.
3. Ask who else can deploy. Deploying is the act of putting a change in front of users. If only one person can do it, the product stops when that person stops. The single-developer risk explains why this is the most important question at pre-seed.
4. Ask what they would rebuild. A founder who has written a real product has a list. A founder who cannot name anything they would change either has not built much or has not looked at it with users.
5. Ask what "we use AI" means. If the deck says AI, ask which model, whose model, what happens when the model is wrong, and whether anyone has measured how often it is wrong. What "we use AI" should mean at pre-seed is the short version; the full method is in the AI startup due diligence guide.
6. Write down what you saw. One page. What ran, what did not, who the names in the commit log were, and what the founder said they would rebuild. In a group, this page is what the technical reviewer hands to the deal lead.

The full timed version, minute by minute, is the one-hour technical check. It is written to be printed and taken into the meeting.

What to check, by question

Is it real? The MVP claim is the one to press first, because "we have an MVP" covers everything from a landing page to a product with paying customers. Y Combinator's Michael Seibel calls an MVP "something ridiculously simple": the first thing you give to your first users "to see if you can deliver any value at all to them". He says most should be built "in weeks, not months". If the startup's MVP took a year, ask what it is. MVP diligence covers what the claim should mean at each stage. For what an MVP is in the first place, launching a product is the guide.

Who built it? At pre-seed the answer is often one person. A 2016 study by Avelino, Passos, Hora and Valente of 133 popular open-source projects on GitHub found that 65 percent had a truck factor of 2 or less, meaning the loss of two people would stall the project. A startup with one developer has a truck factor of one. That is normal at this stage, and it is a risk you should price rather than ignore.

Is there a technical founder, and is that person any good? Evaluating a technical founder gives a non-technical angel five questions that reveal depth without requiring the angel to judge code. It also covers the case where there is no technical founder, which is common and not fatal, provided the company knows who is accountable for the product.

What does the AI claim mean? The regulators have started to act on this. On 18 March 2024 the SEC charged two investment advisers, Delphia and Global Predictions, with making false statements about their use of AI; they paid $225,000 and $175,000. On 25 September 2024 the FTC announced five actions under "Operation AI Comply", including against DoNotPay, which had marketed itself as "the world's first robot lawyer" and agreed to pay $193,000. Both regulators found companies claiming AI they had not built or tested. Your check is the same as theirs: ask for the test.

Is the code safe? If the code was written with AI tools, which at pre-seed in 2026 it almost always was in part, the security question changes. Veracode's July 2025 report tested more than 100 language models and found 45 percent of generated code samples failed security tests. You cannot check that yourself in an hour. You can ask whether anyone has run a security scanner over the code and what it found. Security of AI-written code in diligence covers the full check, and the AI-generated code guide holds the arguments.

The red flags that decide a deal at this stage

A short list, scoped to pre-seed and seed. The general list for a larger deal is on the technical due diligence red flags page.

• The founder will demo but will not screen share a real account.
• The commit history has one name and gaps of weeks.
• Nobody but the founder can deploy, and the founder has not written down how.
• "We use AI" means a call to one vendor's model with no test of the output.
• The security answer is "we have not had a problem".
• The founder cannot name anything they would rebuild.

Technical red flags at pre-seed and seed explains each one, what it means, and which ones should end the conversation.

Common mistakes

Treating the demo as the product. A demo is a rehearsed path through prepared data. It proves the founder can present. Production is the product under a real customer's data, with the mistakes that customer has made. Ask for the second one.

Letting the technical member of the group do the whole review alone. The technical member reads the code. The deal lead still owns the decision, and the reviewer's job is to hand over a page the lead can read. Without a written scope, the reviewer either reads everything and delivers nothing, or reads what interests them. Assigning the technical reviewer in an angel group gives the scope.

Confusing IP questions with technology questions. The UKBAA's technical questions ask whether the technology can be protected by IP rights. That is a legal question. Whether the product runs is a different one, and a patent does not answer it.

Asking for a data room at pre-seed. Y Combinator's guide to seed fundraising tells founders that "if an investor is asking for too much due diligence or financials, they are almost certainly someone to avoid". You do not need a data room. You need one hour, a screen, and the right six questions.

Believing the AI claim because the founder is credible. The SEC and FTC cases were against companies with real customers and real revenue. Credibility is the reason to check, since a credible founder is the one who raises on the claim.

Skipping the check because the cheque is small. The Wiltbank study's median angel spent 20 hours. One of them on the software is the cheapest hour you will spend.

When to pay for a professional review, and what it costs

An angel writing a $25,000 cheque into a pre-seed round should not spend $20,000 on a code review. A syndicate leading a $2 million seed round with a software product at its centre should think about it. The line is where a wrong technical answer costs more than the review.

The prices below are stated by the vendors themselves on their own pages. None has been audited and each vendor sets its own scope.

Vendor	Stated price	Stated duration	Source
MEV	$5,000 to $30,000, quoted upfront	2 to 4 weeks	MEV's technical due diligence guide, updated 5 August 2026
Specialist technical firms	$35,000 to $95,000, at $300 to $600 an hour	Not stated	Papermark, Due Diligence Cost in 2026, updated 19 August 2026
Big Four technology advisory	$50,000 to $150,000, at $400 to $700 an hour	Not stated	Papermark, same page
madewithlove	Not published	2 weeks, up to 8 interviews	madewithlove's guide, 3 May 2024

Reveneau offers a scoped technical review sized for an angel group or syndicate, with the scope agreed in writing before the work starts. When to pay for a professional technical review sets out the decision and the vendor figures in detail, and what technical due diligence costs covers the larger-deal market. If you lead a syndicate or a fund and want the review run for you, the investor page is where to start.

What angels are investing in now

The reason the technology question has moved up the list is that the deals have. The ACA's 2026 Angel Funders Report, published 13 July 2026, reported that ACA member investment rose from $437 million in 2024 to $491.3 million in 2025, and that nearly two-thirds of reporting angel groups completed at least one AI-related investment in the year. The same association's John Harbison wrote in August 2025 that median pre-seed pre-money valuations doubled to $10 million in 2024, and seed rose from the long-standing $7 million to $8 million range to $10 million.

Higher valuations at an earlier stage, on products that increasingly claim AI, is the setting for every page in this guide. The standard checklist was written for a different one.

How this guide is organised

The chapters follow the order an angel meets the questions. Start with what the checklists miss and why the hours matter, then run the one-hour check. The "Is it real" chapters cover the four questions that come up in the meeting itself. The "In a group" chapters are for angel group members and syndicate leads. The "Decide" chapters are the red flags and the buy-or-do-it-yourself call.

Where this guide touches a topic that another Reveneau guide already covers in depth, it links there instead of repeating it: technical due diligence for the full method on a larger deal, AI startup due diligence for AI claims, launching a product for what an MVP is, and preparing for technical due diligence if you are the founder on the other side of the table.