The one-hour technical check a non-technical angel can run alone

The one-hour technical check is a script for a single video call. You do not need to read code, you do not need a technical member of your group on the call, and you do not need a data room. You need the founder, a screen share, this page, and the discipline to ask to see things rather than to hear about them.

Print it. The blocks have times because founders talk, and the hour goes if you let the first block run.

Why is a screen share the whole method?

Because a description of software is free and a demonstration of software is not. A founder can describe a product that does not exist. A founder cannot log in as a customer to a product that does not exist. Every block in this check is therefore an instruction to show, followed by an instruction to watch.

The check covers the four questions the standard angel checklists do not ask, which what angel diligence misses on technology documents: does the product run for real users, who can change it, what breaks when the founder is away, and what the AI claim means. It fits inside the diligence time angels already spend. In Wiltbank and Boeker's November 2007 study of 539 group angels, the median angel spent 20 hours per investment; this is one of them.

Reveneau's angel review runs the same six blocks, and its first request is always the product on a real account, because that block alone resolves more pre-seed deals than the other five combined.

Minutes 0 to 15: is the product running on a real account?

Ask: "Please log in as one of your customers, with their permission, and do the thing your deck says customers do." Then: "Now show me the last thing that customer did in the product."

Look at: the login. A demo account has a tidy name and tidy data. A real account has a company name you can search for, data with mistakes in it, and history. Watch whether the founder goes to a bookmarked demo environment or to the same address a customer would use. Watch whether the thing the deck describes takes one click or a workaround.

Good answer: the founder logs in to a real account, the product does what the deck says, and somewhere in the first five minutes the founder says "this part is slow" or "we are rebuilding this screen". Real products have parts their builders dislike.

Bad answer: "let me show you on our demo account, the customer data is confidential." Customer data can be shown with a customer's permission, and a founder raising money has asked for that permission before. A second bad answer is a video. A third is a product that works on the demo path and errors when you ask for one step off it.

Write down: whether it was a real account, whether the deck's claim ran, and the first thing the founder said they disliked. Demo versus production has the full list of tells for this block.

Minutes 15 to 25: who has been changing the code, and when?

Ask: "Please open your code repository and show me the history of changes for the last three months."

Look at: the list of changes, which every version control system shows as a log with a name, a date and a one-line description per entry. You are counting two things. How many different names appear, and how the dates are spaced. You are also reading the one-line descriptions, which are written for other developers and are honest in a way pitch decks are not: "fix login crash again" tells you something.

Good answer: the founder opens the log without hesitation, there are entries from this week, the dates are steady rather than clustered, and the descriptions make sense to a lay reader at least half the time. Two or more names is better than one, and one name at pre-seed is normal rather than disqualifying.

Bad answer: "I would need to check with my developer." That sentence means the founder does not have access to the company's own code, which at pre-seed usually means the code is owned by a contractor, an agency, or a friend. A second bad answer is a log with a gap of weeks and then a burst of entries the week before your meeting.

Write down: the number of names, the date of the most recent entry, and the longest gap.

Minutes 25 to 35: who else can deploy?

Ask: "If you were unreachable for a month starting tomorrow, who could put a fix in front of customers, and where are the instructions they would follow?"

Look at: whether the founder can point at a document. Deployment is the act of putting a change live. It is a sequence of steps that someone knows. If the steps are only in one person's head, the product stops when that person stops. Ask to see the document, or the automated pipeline that replaces it.

Good answer: a name, and a file on screen, even if the file is short and out of date. Or an admission: "nobody, and that is why the second hire in this round is an engineer." Both are honest. The second is common at pre-seed and is a risk to price rather than a reason to walk away.

Bad answer: "it is all in the cloud so it is fine." The cloud hosts the product; it does not know how to change it. A second bad answer is a name that turns out to be a contractor who no longer works with the company.

Matt Van Itallie's October 2022 checklist on TechCrunch, written for founders about to face technical diligence, asks the same thing from the other side: list current and former developers, identify who the most important developers are, and if any have left, explain how the company managed without them. The single-developer risk covers why this block matters most at pre-seed.

Write down: who else can deploy, and whether the instructions exist.

Minutes 35 to 45: what would the founder rebuild?

Ask: "What part of the product would you rebuild if you had a free month, and why?"

Look at: the founder's face and the speed of the answer. This is the one block where the screen matters less. A person who has built a real product and watched users use it has a list, and the first item comes out fast with a reason attached.

Good answer: a specific part, a reason grounded in users or in cost, and a sense of what the rebuild would cost. "The onboarding flow, because half of trial users drop at step three, and it is two weeks of work" is a good answer whether or not the numbers are right.

Bad answer: "nothing, it is solid." Or a long pause followed by a marketing feature rather than a rebuild. Either means the founder has not looked at the product with users, or has not built enough of it to have opinions.

Write down: the part and the reason, in the founder's words.

Minutes 45 to 55: what does the AI claim mean?

Ask, if the deck says AI: "Which model, whose is it, what happens when it gives a wrong answer, and how often does it?" Then: "Show me how you measured that."

Look at: whether there is a test. A startup that has measured how often its AI feature is wrong has a file, a spreadsheet, or a dashboard with a number in it. Ask to see it on screen. If the answer is that the model is a third party's, ask what the product does that the third party's own product does not.

Good answer: a named model, a stated failure rate with the method behind it, and a description of what the user sees when the model is wrong. A founder who says "it is wrong one time in eight on our test set and we show the source so the user can check" has done the work.

Bad answer: "we use the latest model and it is accurate." No number is a claim without a test. The regulators now treat that as a problem: in March 2024 the SEC fined Delphia $225,000 and Global Predictions $175,000 for AI claims they could not support, and in September 2024 the FTC settled with DoNotPay for $193,000 after finding it had not tested whether its "robot lawyer" matched a lawyer's work.

What "we use AI" should mean at pre-seed is the short version of this block, and how to verify an AI claim with a test is the full method.

Write down: the model, the number, and whether you saw the test.

Minutes 55 to 60: has anyone checked security?

Ask: "Has anyone outside the team run a security scan on the code, and what did it find?"

Look at: whether there is a report. You are not judging the findings. You are checking whether the question has ever been asked.

Good answer: "yes, in month, it found these things, we fixed these and left these." Or "no, and we know we need to before the first enterprise customer."

Bad answer: "we have not had a problem." Absence of an incident is not evidence of security. This matters more when the code was written with AI tools, as most pre-seed code now is in part: Veracode's July 2025 report tested more than 100 language models and found 45 percent of generated code samples failed security tests, with Java the worst at 72 percent.

Write down: whether a scan has been run, and when.

What does the one-page output look like?

Block	What you saw	Flag
Product	Real account or demo; did the deck's claim run; first thing the founder disliked
Commit history	Number of names; date of last entry; longest gap
Deployment	Who else can deploy; do written steps exist
Rebuild	The part and the reason
AI claim	Model; measured failure rate; test seen or not
Security	Scan run or not; date

Fill the Flag column with one of three words: fine, price it, or stop. "Stop" belongs on a refused screen share of a real account and on a founder with no access to the company's code. "Price it" belongs on a single developer with no written deployment steps and on an AI claim without a test. Everything else is "fine" with a note.

If the page has two or more "stop" flags, or the round is large enough that being wrong costs more than a review, when to pay for a professional technical review is the next step. Otherwise the page goes to the deal lead, and the pillar page explains where it sits in the rest of the decision.

What should you not do in the hour?

Do not ask for a data room. Y Combinator's guide to seed fundraising tells founders that an investor asking for too much diligence or financials at seed is one to avoid, and a founder who has read it will treat a document request as a signal about you. Do not ask to see the code itself; you cannot read it and the request makes the founder defensive for nothing. Do not let the founder drive the demo; you choose the account and the task. And do not skip a block because the founder is credible. The SEC and FTC cases were against companies with real customers.