What an MVP should actually contain

The phrase "minimum viable product" has been stretched until it means almost nothing. To some people it means a landing page; to others it means the full product with one feature removed. Neither definition helps you decide what to build on Monday.

Start from the riskiest assumption

Every product rests on a belief that might be wrong. Sometimes it is a demand question: will anyone pay for this? Sometimes it is technical: can we process this reliably enough to be trusted? The MVP exists to test whichever belief would be most expensive to discover is false.

Write that assumption down as a sentence before scoping anything. If your feature list does not test it, the list is wrong.

Minimum does not mean shoddy

Cutting scope is not the same as cutting quality. A small product that works is a test; a large product that breaks is noise. If sign-in is unreliable, you learn nothing about whether people want the thing behind sign-in.

What we usually keep

—One complete path through the product, end to end, with no dead ends.

—Accounts, if the value depends on returning users.

—Instrumentation, because an MVP you cannot measure has not tested anything.

—A way to contact a real person, which is the highest-signal feedback you will get.

What we usually cut

—Admin tooling that a spreadsheet can cover for the first few months.

—Settings screens, which are usually a decision you have not made yet.

—Second platforms, until the first one shows the idea works.

None of this is a rule. It is a starting position we argue with, project by project — and we would rather argue about it in week one than in month six.