MVP diligence: what having an MVP should mean

"We have an MVP" is the most common technical claim in a pre-seed deck and the least defined. This page is about what it should mean, how to find out which of four things it means in a given deal, and what a good answer looks like at each stage. It assumes you know what an MVP is; if you do not, the launching a product guide covers that, and this page does not repeat it.

What should the claim mean?

Take the definition from the people who popularised the term for startups. In his August 2019 Y Combinator talk on planning an MVP, Michael Seibel says the MVP is "something ridiculously simple", the first thing a founder can give to the first users they want to target, "in order to see if you can deliver any value at all to them". He says most founders should build a lean one "in weeks, not months", and that the goal of a pre-launch startup is to "launch something bad, quickly".

Two things in that definition are the diligence standard. First, the users are part of it. An MVP is given to people. A product that has been built and shown to nobody is a prototype, whatever the deck calls it. Second, the point is learning. The founder who has an MVP has found out something from those users and changed something because of it.

So "we have an MVP" should mean: there is a working version, a specific set of first users has it, and the founder can tell you what those users did and what changed as a result. Anything less is a different claim, and the different claims are fine to invest in. They are priced differently.

Reveneau's angel review asks which of four claims "we have an MVP" stands for before it asks anything else about the product, because the answer sets the scope of every later question.

Which of the four claims is it?

Claim	What exists	Evidence to ask for	Normal at
Prototype	A working version, no users	The product, shown live	Pre-seed, early
Used by friends	Users the founder knows personally	Two names who will take a call	Pre-seed
Used by strangers	Users the founder did not know before	Sign-up dates and usage on screen	Pre-seed to seed
Paid for by strangers	Revenue from users the founder did not know	Invoices or a payment dashboard	Seed

The questions that sort a deal into a row are short. "Who has used it?" If the answer is a number, ask for two names. If the names are co-founders, former colleagues or family, it is the second row. "How did they find it?" If the founder introduced every one of them, it is still the second row. "Has anyone paid?" If yes, ask to see the payment on screen, because a screenshot of a Stripe dashboard is the easiest document in the world to prepare.

Ask the questions in that order and stop at the first row where the evidence runs out; that row is the deal, and the row above it is the deck.

None of the four rows is a reason to stop. Wiltbank and Boeker's November 2007 study of 1,137 angel exits found that 45 percent of the ventures had no revenue when the angel invested, and the median revenue across all of them was $125,000. Pre-revenue is what pre-seed means. The flag is a mismatch between the row the deck implies and the row the evidence supports.

What does a good answer look like at pre-seed?

At pre-seed, a good answer is the second or third row with specifics. The founder names users, says how many, says when they started, and tells you one thing those users did that surprised the founder and one thing that changed in the product because of it.

The ACA's July 2007 due diligence guide gives the business-side version of this bar. Under customer relationships it says that "having two established customers who will confirm that they are buying or will buy the product is a good hurdle". At pre-seed, before there is anything to buy, the equivalent is two named users who will take a fifteen-minute call and describe what they did with the product. Hustle Fund's angel checklist, which schedules most angel diligence over 1 to 3 weeks, includes customer discovery calls for the same reason.

A weaker answer, still acceptable, is the first row said plainly: "we have a working prototype, nobody has used it yet, the first five users start next month, and here are their names". That is a pre-seed company being honest, and it moves the technical question from the product to the founder, which evaluating a technical founder covers.

The bad answer is the first row described as the third. "We have an MVP and early traction" with no names, no dates and no usage on screen. Y Combinator's guide to seed fundraising warns founders that investors want to know the product "is experiencing actual growth" before they are persuaded, and a founder who has read it will sometimes describe growth that has not happened yet.

What does a good answer look like at seed?

At seed, "we have an MVP" is the wrong sentence. A company raising a seed round should have moved past the MVP: strangers using the product, some of them paying, and the founder able to say which parts of the MVP were thrown away. If the seed deck still says MVP, ask why. Sometimes the answer is a pivot, which is fine and should be dated. Sometimes the answer is that the pre-seed money was spent on a product nobody used, which is the thing to know.

The evidence at seed is on screen: sign-up dates, usage by account, revenue by month. The check for whether that screen is production rather than a prepared view is in demo versus production. For a seed round large enough to justify a proper review, technical due diligence scope by stage describes what a firm would look at.

How long should the MVP have taken?

Seibel's guidance is weeks. His talk distinguishes a lean MVP, which most startups should build, from what he calls a heavy MVP, needed in regulated industries such as insurance or banking, in hardware, or in biotech, where launching quickly is blocked by regulators or physics.

For a software startup outside those cases, an MVP that took a year to build is a question in itself. Either it is a heavy MVP for a stated reason, or the founder built for a year without users, which is the opposite of the advice. Ask when the first user touched the product and compare that date to when the code was started. The commit history block of the one-hour technical check gives you the second date.

AI coding tools have shortened the build side of this and left the user side unchanged. A founder can now produce the working version in days, and a founder who says the MVP took a weekend may be telling the truth. Whether anyone has used it still takes as long as finding users takes, because users do not arrive faster when the code does. That is why the questions on this page are all about users and none are about how much was built.

What should an angel not do?

Do not ask for an MVP document. Y Combinator's seed guide says that an investor who asks for "too much due diligence or financials" at seed is one to avoid, and an angel who asks for a written product specification from a pre-seed company is asking for something that should not exist yet. The MVP is the specification. Ask to see it, ask who has used it, and ask what changed.

Do not treat the fourth row as required at pre-seed. Paying strangers is a seed-stage bar, and applying it earlier means passing on companies that are exactly where they should be.

Do not let "MVP" and "in production" blur together. A product used by five friends is an MVP. A product used by fifty strangers on the live address is in production. The founder may use the same word for both; the angel should not, and the pillar page keeps the two questions separate for that reason.