Assigning the technical reviewer in an angel group or syndicate

An angel group has a member who has built software. Sometimes several. The question is how to use them on a software deal without either wasting their time on the whole review or handing them the decision. This page is the answer: one reviewer per deal, a written scope, a one-page output, and a deal lead who stays in charge.

What do the angel playbooks already say about splitting diligence?

More than you might expect, and none of it specific to technology.

The ACA's July 2007 due diligence guide advises that a group "probably doesn't want to do full due diligence on more than one or two deals a month", and that "preferably at least one member should have experience in the relevant domain so that he or she can take the lead". The UKBAA's September 2020 guide says that when investors work as a syndicate, diligence "is normally shared between the investors, each taking on areas where they have the knowledge or expertise or key contacts, generally with a lead investor who will directly interact with you and your business".

The Golden Seeds playbook from January 2010, the most operational of the three, describes forming a due diligence team by drawing in members "whose expertise, advice and/or contacts are needed", with roles listed as financial, sector expertise, marketing, and "other, deal specific". It says the lead investor "is not meant to do all the work". On technology specifically it says to "obtain opinions from experts in the field", some provided by the founder and some found in the group's own network, and it allows an NDA for that expert as the one exception to the group's no-NDA rule.

So the structure exists. What is missing is a definition of what the technology expert checks and what they hand back. Without that, the reviewer either reads everything and delivers a verbal impression, or reads what interests them. Both outcomes look like diligence from the outside and neither gives the deal lead a sentence they can act on, which is why the scope on this page is written down before the founder call rather than agreed in the meeting afterwards.

Who should be the reviewer?

The member who has built and shipped software, recently, at a company of the size the target will be in eighteen months. Three tests help.

Have they shipped, or have they managed? A member who ran a 200-person engineering organisation ten years ago has judgment about teams and less about what a two-person product looks like on screen today. A member who built a product in the last five years, even a small one, knows what a commit history and a deployment pipeline look like now.

Do they know the domain? Wiltbank and Boeker's November 2007 study found that half of angel investments were unrelated to the investor's industry experience, and that investment multiples were twice as high for investments connected to it. The study measured the angel's expertise, not the reviewer's, and the direction is the same: a reviewer who knows the customer's world knows which technical claims matter.

Are they willing to write one page? The output is the point. A reviewer who will only give a verbal opinion in the meeting is giving the group an impression, and impressions do not survive the week between the meeting and the decision.

If no member passes the tests, the group has two options: run the one-hour technical check, which is written for a non-technical member, or pay for a review, which when to pay for a professional technical review covers.

What is the written scope?

Four questions, agreed before the founder call, written on the same page the answers will go on.

1. Does the product run for real users? A screen share on a real customer account, with the tells from demo versus production.
2. Who can change it? The commit history: how many names, how recent, how steady.
3. What breaks when the founder is away? Who else can deploy, and whether the steps are written.
4. What does the AI claim mean? Which model, whose, what happens when it is wrong, and whether that has been measured.

The scope also says what is out. Reading the code is out, unless the group has agreed a paid review. Architecture opinions are out at pre-seed. Security beyond "has anyone run a scan" is out. A reviewer who wants to go further should say so in the page and the group can decide whether to pay for it.

Reveneau's angel review uses this four-question scope as its standard engagement for groups and syndicates, and delivers the same one-page format so that a group can compare a paid review with its own member's on the deals where it has both.

What does the one-page output look like?

Question	What was seen	Flag	One line for the lead
Runs for real users?	Real account at Northgate; invoicing ran; export failed	Price it	Product is in production; one feature in the deck does not work yet
Who can change it?	Two names; last change three days ago; longest gap nine days	Fine	Two people commit regularly
Founder away a month?	Co-founder can deploy from a written page	Fine	Deployment is not a single point of failure
AI claim?	Third-party model; no failure rate measured	Price it	The AI feature is a vendor call with no test; ask for one before close

The example rows are illustrative; the columns are the fixed part. Three flags only: fine, price it, stop. The "one line for the lead" column is the part that matters, because it is what the deal lead will read aloud in the meeting. It has to be plain. "The AI feature is a vendor call with no test" is plain. "Inference is unevaluated" is not.

How does the deal lead keep the decision?

By treating the reviewer as a witness rather than a second lead. The reviewer reports what they saw and flags it. The lead decides what the flags mean for the terms and the cheque.

Three habits keep that line clear. The reviewer's page goes to the lead before the group meeting, so the lead can ask questions in private. In the meeting, the lead presents the technical findings in their own words and the reviewer answers questions. And the reviewer does not vote on the deal in the technical discussion; they vote as a member afterwards, like everyone else.

The reason is the one the ACA guide gives under "Gut vs. Brain": angels have an advantage over venture funds in being able to decide quickly, and that advantage disappears if every deal waits for the technical member to be satisfied. A reviewer with a scope and a page finishes in a week. A reviewer with no scope finishes when they lose interest.

The lead also decides when a "price it" flag is worth a term and when it is worth a smaller cheque, which is a judgement about the round rather than the technology and belongs with the lead.

In a syndicate rather than a group, the same structure applies with one change: the syndicate lead is usually also the person who found the deal and likes it. The reviewer's page is the check on that, and the lead should ask for it before circulating the deal memo rather than after.

What goes wrong?

Four things, all avoidable.

The reviewer reads the code. They were not asked to, but they can, so they do. Three weeks later they have opinions about the framework and no page. The scope prevents this if the lead enforces it.

The reviewer is the group's only technical member and reviews every deal. They burn out or start declining. Rotate the role where possible, and use the one-hour check to let non-technical members carry the first pass.

The page uses words the lead cannot read. The lead should send it back. If the reviewer cannot say it plainly, the group cannot act on it.

The reviewer's flag becomes a veto. "Price it" means the group asks for a term. "Stop" means the group asks for something to be shown before continuing. Neither means the deal is dead until the lead says so. The pillar page frames the technical check as one input among the five the group already runs, and how to run technical due diligence shows what the scoped version looks like when a firm does it on a larger deal.