Building your first MVP without wasting a year

An MVP is not a cheap version of your final product. It is the smallest release that lets you learn whether people want what you are building.

Start with one user and one job

Write down who the first user is and the single task they hire your product to do. Every feature should serve that job or wait.

Cut by risk, not by effort

List your assumptions and rank them by how badly the product fails if they are wrong. Build to test the riskiest ones first, even if they are not the easiest.

Prototype before you code

A clickable prototype can be built in days and tested with real users. It is the cheapest way to find a bad idea.

Plan for the boring parts

Authentication, permissions, backups, email and error handling are not optional. They are what makes an MVP trustworthy enough to put in front of customers.

Decide how you will measure it

Before launch, agree three numbers that tell you if the MVP worked. Without them, every result becomes an argument.

Done well, an MVP takes weeks, not quarters, and gives you evidence to invest further, or to stop early and save money.