Evaluating a technical founder, and what to do when there is none

A technical founder is judged on the same things as any founder, plus one. The standard angel checklists cover the general things well: credentials, references, judgment, honesty, and whether you can work with the person for the next five to seven years. The extra thing is whether this person can keep building the product and hand it on to the people who will join. This page is about that extra thing, for an angel who does not write code, and about the company where nobody has the job.

What do the standard checklists already get right?

Management is the part of angel diligence with the most practice behind it, and the practice transfers. The ACA's July 2007 due diligence guide says that "the one thing that everyone in the venture industry is in harmonious agreement on is that management is absolutely critical and the single most important aspect of a deal". Its list is credentials, a legal background check, mindset, leadership, honesty and integrity, intelligence, and judgment.

Its reference method is the useful part. The guide quotes David Rose of New York Angels on talking to the references a founder provides and then asking those references for more names, and John May of New Vantage Group on taking that a step further, to the point that he "expects to have around 30 conversations". The Golden Seeds playbook from 2010 adds the instruction to look at the list of references and "think hard about who is NOT on the list that should be", such as the CEO of a startup the founder used to work at.

For a technical founder, that method works with one adjustment: the reference you are looking for is someone who watched this person ship software under pressure. A former engineering manager, a co-founder from a previous project, a senior engineer who reviewed their work. Ask each reference for the name of one such person. The chain usually gets there in two steps.

The UKBAA's September 2020 guide adds the question of what the team stand to lose if the business fails, and whether they can survive on a limited income. For a technical founder that has a specific form: could this person get a well-paid engineering job tomorrow, and what is keeping them here?

What five questions reveal depth without judging code?

These are the questions Reveneau's angel review puts to a technical founder in the first meeting, and none of them requires the person asking to read the answer's code.

1. "What part of the product would you rebuild, and why?" Someone who has built and watched users has a list, and the first item comes out fast with a reason. A pause followed by "nothing" is the answer of someone who has not built enough to have regrets. This question also appears in the one-hour technical check, where it has ten minutes.

2. "What broke last, and how did you find out?" Every product breaks. A founder who can name the last failure, say how they learned of it (a user, an alert, a test), and say what changed afterwards has run a product. A founder who says nothing has broken has either not launched or is not watching.

3. "What did you choose not to build, and what did it cost you?" Judgment shows in omissions. A technical founder with good judgment can name features they refused, and can name a customer they lost as a result. The answer tells you whether this person can say no to the sales side, which is the argument they will have every week.

4. "Who taught you the most about building software, and what did they teach you?" This is a proxy for whether the founder has worked alongside better engineers. A specific name and a specific lesson means they have. A vague answer means they may have learned alone, which is fine for a first product and a problem for a team.

5. "What do you not know how to do that this company will need in the next year?" The best answer names a gap and a plan: "I have never run infrastructure at scale, so the second hire is someone who has." The worst answer is that there is no gap.

Leo Polovets, who wrote the 2016 essay "Startup Technical Diligence Is a Waste of Time" that reached 287 points on Hacker News, described in the thread using his own technical background as "a baloney detector and a good differentiator from VCs who have non-technical backgrounds". The five questions are a baloney detector a non-technical angel can hold.

What does the screen share add?

One thing the questions cannot: whether the founder can explain the product to someone who will inherit it.

Ask the founder to open the code repository and, without going into the code, describe how the product is organised: where the customer-facing part lives, where the data is stored, what happens when a user does the main thing. You are listening for whether the explanation is ordered, whether it uses plain words, and whether the founder points at real things on the screen. A founder who can do this can onboard the second engineer. A founder who cannot will be the bottleneck for every hire, which is the single-developer risk in a different form, and the single-developer risk covers what to ask for in the round.

The commit history on the same screen tells you whether the founder is the person who wrote the product. If the founder claims the technical role and the log shows a different name, ask who that is.

What should you do when there is no technical founder?

First, do not treat it as disqualifying. Many pre-seed companies have a business founder and a contractor, an agency, or a technical friend, and some of them become good companies. The question is whether the gap is named and priced.

Situation	What to ask	What good looks like
Contractor built the product	Who owns the code, what is the contract, how many hours a week, what else are they on	Assignment agreement signed, retainer in place, second engineer in the plan
Agency built the product	Who has the repository, who can deploy, what does the agency charge to change one screen	Code in the company's own repository, a named person who can deploy without the agency
Technical friend on equity	Are they committed full time, what is their vesting, what is their day job	Full-time with vesting, or an honest part-time arrangement with a hire planned
Business founder plans to hire	What month, what budget, who is helping them interview	A month, a number in the use of funds, and a technical advisor who will sit in on interviews

The flag in every row is the same: a company that describes a contractor as if they were a co-founder, or a founder who says the technology is "handled" without being able to say by whom. The ACA guide's advice to check what the founder stands to lose applies to the technical contributor too. A contractor stands to lose a client.

Some companies fill the gap with a part-time senior engineer rather than a hire. Fractional CTO versus software development agency is the comparison, and the fractional CTO comparison page covers when that role is the right answer and when it becomes another bus factor of one.

What is different when the deal is bigger?

At pre-seed, this page is the team assessment. At seed with a team of four or five, the questions extend to how the team works together, who reviews whose code, and whether the technical founder has hired anyone before. Assessing the engineering team is the fuller method a firm would run on a later deal, and it is the page to read if the round is large enough that a wrong answer costs more than a review.

In an angel group, this assessment is usually split: a non-technical member runs the references and the general management questions from the ACA list, and the member assigned as technical reviewer runs the five questions and the screen share. Assigning the technical reviewer in an angel group covers how to divide it, and the pillar page puts the founder assessment next to the other checks.

What should you write down?

Five lines: the rebuild answer, the last-break answer, the gap the founder named, the name of the reference who saw them ship under pressure, and whether the founder could explain the product's organisation on screen in plain words. If there is no technical founder, replace the last line with who owns the code and what month the first engineer starts.