Technical red flags at pre-seed and seed

A red flag at pre-seed is something you can see on a screen that changes what the deal is. This page lists nine, scoped to pre-seed and seed only, and sorts them into three groups: the two that stop the conversation, the four that become terms, and the three that are normal at this stage and should be written down rather than acted on. The general list for a Series A or later deal is on the technical due diligence red flags page, and the AI-specific list by stage is on AI startup diligence red flags by stage. Neither is repeated here.

Which two flags stop the conversation?

The founder will demo but will not screen share a real customer account. Customer data can be shown with a customer's permission, and a founder raising money has asked for that permission before you did. A founder who offers the demo account instead, twice, is telling you that either no customer is using the product or the product does not survive a real account. Both are things to know before the cheque. Ask once more, in writing, and wait for the answer before any further meeting. Demo versus production has the tells if the account you are then shown is still a demo with a customer's name on it.

The founder cannot open the company's own code. When you ask to see the commit history and the answer is "I would need to check with my developer", the company does not control its product. The code lives with a contractor, an agency, or a former co-founder, and until it lives in a repository the company owns, with a signed assignment of the work, the company is buying its own product back one invoice at a time. This is the single-developer risk in its worst form, and the single-developer risk covers the cases where it is fixable.

Neither flag means the deal is dead. Both mean the deal is paused until something is shown, and the founder should be told in plain words what that something is: a real account on screen, or the repository open with the founder logged in. Most founders can produce both within a week. A founder who cannot has told you what the pause was for. Reveneau's angel review treats these two as the only "stop" flags at pre-seed, because every other finding on this page can be priced, and these two cannot be priced until they are resolved.

Which four flags become terms?

One developer and no written deployment steps. A bus factor of one is normal at pre-seed. A bus factor of one with the deployment sequence in one person's head is a term: written steps within thirty days, a second person with access, and a second engineer as a named use of funds. The 2016 study by Avelino, Passos, Hora and Valente found 65 percent of 133 popular open-source projects had a truck factor of 2 or less, so the concentration is common; the absence of a plan to reduce it is the flag.

An AI claim with no test. "We use AI" with no named model, no measured failure rate and no fallback for a wrong answer is a marketing line. The term is a test before close: twenty inputs, pass or fail, a number. The SEC's March 2024 fines against Delphia ($225,000) and Global Predictions ($175,000) and the FTC's September 2024 settlement with DoNotPay ($193,000) were all for AI claims with nothing behind them. What "we use AI" should mean at pre-seed is the ten-minute check.

No security scan, ever. At pre-seed this is common and it becomes a flag when the code was written with AI tools and the company sells to businesses. Veracode's July 2025 report found 45 percent of code samples from more than 100 language models failed security tests. The term is a scan before the first enterprise customer, with the results shared with the board.

A commit history that moves only before investor meetings. Scroll back three months. If the log shows gaps of weeks and then a burst of changes in the days before each pitch, the product is being built for the pitch. The term is a monthly product update to investors with the commit count in it, which costs the founder nothing and makes the pattern visible to everyone on the cap table from the first month.

Which three flags are normal at pre-seed?

These belong in the notes. Acting on them means passing on companies that are exactly where they should be.

One developer. A pre-seed company with one engineer is a pre-seed company. Wiltbank and Boeker's November 2007 study of 1,137 angel exits found 34 percent of deals were done at the seed stage and 41 percent at the start-up stage; small teams are the population. Note the bus factor and move on to whether there is a plan.

No revenue. The same study found 45 percent of ventures had no revenue when the angel invested and the median across all of them was $125,000. Pre-revenue is not a technical flag. Unused is, and MVP diligence separates the two.

A product that changed shape between meetings. At pre-seed the product should be changing. A founder who shows you a different onboarding flow from the one you saw last month has been watching users. The flag is the opposite: a product that looks identical three months apart while the commit history shows work, which usually means the work went somewhere the customer does not see.

What does the full list look like in one place?

Flag	What you see	Group	Action
No real account shown	Demo account offered twice	Stop	Ask in writing, wait
Founder cannot open the code	"I would need to check with my developer"	Stop	Assignment agreement and repository access before continuing
One developer, no written deployment	Deployment steps in one head	Term	Written steps in 30 days, second engineer in use of funds
AI claim, no test	No model named, no failure rate	Term	A test before close
No security scan	"We have not had a problem"	Term	Scan before first enterprise customer
Commits only before pitches	Gaps, then bursts	Term	Monthly update with commit count
One developer	One name in the log	Normal	Note the bus factor
No revenue	Pre-revenue company	Normal	Check that users exist
Product changed shape	Different flow from last month	Normal	Ask what users said

Why is the list this short?

Because long checklists fail in a specific way. In March 2023 a 100-question diligence checklist reached 253 points on Hacker News, and the top comment warned that "there are precisely zero companies in the world to which the answer to all of these questions is positive", and that many of the questions contradict each other across company sizes. A checklist with a hundred items gives the angel a hundred things to feel bad about and no way to rank them.

Nine items, in three groups, with an action against each, is a list an angel can carry into a meeting and act on afterwards. It is also a list a founder can be told about in advance, which is fair: Y Combinator's guide to seed fundraising tells founders that an investor asking for too much diligence at seed is one to avoid, and a founder who knows the nine things you will look at can prepare them in an afternoon without building a data room.

The pillar page places these flags inside the six-block check they come from, and the one-hour technical check is where each flag is first seen. If a deal shows both 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 page.

What is deliberately not on this list?

Architecture. Choice of programming language or framework. Test coverage percentages. Cloud cost. Code quality as a technical reviewer would judge it. All of these matter at Series A and are on the general red flags page. At pre-seed the product is small enough that the wrong framework is a month's rewrite, and the questions that decide the deal are whether it runs, who can change it, and whether the claims are true.