What angel diligence misses on technology

Angel diligence misses technology because the documents that define good practice for angels were written around four things an experienced business person can judge without help: the management team, the market, the financial projections, and the legal position. Software is treated as a subset of intellectual property, and intellectual property is treated as a legal question.

That is a fair description of how the field thinks, and it is why a non-technical angel ends up with no questions to ask about the product beyond "can I see a demo". This page goes through the two most cited documents to show exactly what is there and what is missing.

What does the ACA's 2007 due diligence guide cover?

The Angel Capital Association's "Best Practice Guidance for Angel Groups: Due Diligence" was written by David Eyler of Columbia University in July 2007 and remains the document the association points members to. Read in order, its sections are: Defining the Risk of the Investment Opportunity; When to Start Due Diligence; Creating a Due Diligence Plan; Non Disclosure Agreements; Reasons Deals are Rejected; a second Creating a Due Diligence Plan section covering the business plan, site visits and references; Gut vs. Brain, on how much analysis is appropriate; and a Conclusion.

Within those sections the guide is thorough about people. It tells a group to check credentials, run a legal background check, judge mindset, leadership, honesty and judgment. It quotes David Rose of New York Angels on asking references for more names, and John May of New Vantage Group, who "expects to have around 30 conversations" per deal. It is thorough about the market, the business model, the financial projections, the deal structure and the exit.

Technology appears in two places. Under "Creating a Due Diligence Plan", the first assumption to confirm is "Viability of IP", followed by three paragraphs from a patent lawyer about filing deadlines and claim scope. Under "Defining acceptable risks", the guide notes that "if the firm is developing a new technology, there is a risk that it won't work or, more likely, that it won't work in time to be relevant", and then says that ruling out every venture with that risk would eliminate some of the best deals.

That is the whole treatment. There is no section on the product, no question about whether it runs, no question about who wrote it, and no mention of code.

What do the UKBAA's eight technical questions ask?

The UK Business Angels Association published "The due diligence process" in September 2020. It says investors focus on five areas: Management, Finance, Legal, and Commercial, with Commercial split into market questions and a Technical heading. The Technical heading has eight numbered questions. In the order the document gives them, they ask:

1. Whether it is a stand-alone technology or relies on other technology or businesses, and how reliant.
2. Whether the company needs to license in technology from other providers.
3. Whether it is a platform technology usable for many applications, and if so whether one application has been prioritised.
4. Whether the technology can be protected by intellectual property rights, and how, and in which markets.
5. Whether it is an incremental improvement or a disruptive innovation.
6. Whether the technology is ready to go to market, and if not, what the major developmental obstacles are.
7. Which major companies are active in the space and what they are working on.
8. What the current technology trends are and whether the idea will be overtaken before it reaches market.

Every one of these is a good question. Every one is also a question about position: where the technology sits relative to other technology, other companies, IP law and the market clock. Question six comes closest to asking whether the software works, and it asks the founder to name obstacles rather than asking the investor to look.

The management section of the same document does contain one technical question in disguise. Its eighth point asks how long the team have known each other and what happens if one of them leaves. At pre-seed, where the team is often one developer, that is the bus factor question, and it is filed under management.

What does the one angel playbook that names technology tell a group to do?

The Golden Seeds Due Diligence Playbook, dated January 2010 and hosted on the ACA's site, is the most operational angel document in circulation. It describes a deal team with roles for financial, sector expertise, marketing and "other, deal specific". In its Review section, the first assessment listed is technology, and the instruction reads: "Technology - need to obtain opinions from experts in the field. Some experts will be provided by the entrepreneur. We also need to dig amongst our networks to find our own."

The playbook's NDA section makes the same point from the other side. Angel groups do not sign NDAs, it says, with one exception: "we will sometimes want to have an expert (either inside or outside our group) help us evaluate a company's technology", and that expert may be asked to sign one.

So the most detailed angel process document treats technology as something to outsource to an expert. That is correct for a medical device. For a software startup at pre-seed, it means the group either has a member who writes code or it has no view at all. Assigning the technical reviewer in an angel group is about making that assignment deliberate.

Reveneau's angel review exists for the gap those three documents leave: it is a scoped check of whether the software runs, who can change it, and what the AI claim means, written up on one page for a deal lead who does not write code.

Why does the gap matter more now than in 2007?

Three things have changed since the ACA guide was written, and each makes the missing section more expensive.

The first is that the software is the company more often. In Wiltbank and Boeker's 2007 study of 1,137 angel exits, software was the largest industry at 19 percent of exits, followed by health and biotech at 18 percent. A 2007 checklist that covered technology through patents was covering a large share of its deals badly even then.

The second is that the product can now be built in weeks by one person with AI tools, which makes a convincing demo cheaper and a durable product no cheaper. The difference between the two is exactly what the checklists do not ask about. Demo versus production is the page for that.

The third is that the claim itself is now regulated. In March 2024 the SEC fined two advisers a combined $400,000 for AI statements they could not support, and in September 2024 the FTC brought five cases under Operation AI Comply. An angel who does not ask what the AI claim means is relying on the founder to have asked themselves.

What is left for the angel to ask alone?

Four questions fall through all three documents. They are the spine of this guide.

Question	Where the checklists put it	What the angel has to do
Does the product run for real users?	Nowhere; "Is the technology ready to go to market?" asks the founder to say so	Watch it on a real account, live
Who can change the product?	Management, as "what happens if one leaves"	Read the commit history and ask who else can deploy
What breaks when the founder is away?	Nowhere	Ask what is written down
What does "we use AI" mean?	Nowhere	Ask for the test

None of these needs code access and none needs a technical reviewer. The one-hour technical check turns them into a timed script. For the full version of what a checklist should contain on a larger deal, the technical due diligence checklist is the reference.

Does this mean the published checklists are wrong?

No. Both documents say true things about the parts of a deal they cover, and the ACA guide's advice on references, site visits and proportionality is as good now as it was in 2007. Its own "Gut vs. Brain" section quotes John May's view that analysis should be proportionate to the stage, "later = more", and that is the right frame for an angel: a pre-seed technical check should take an hour, and a Series B one should take weeks.

What the documents lack is the hour. This guide supplies it, and the pillar page puts the hour in the context of everything else an angel checks. Why the hours you spend on diligence matter is the evidence that the hour is worth spending.