- MVP
- Building
Ten rules for building an MVP
By Ahmed Gadir
Published
Summary
An MVP is the smallest version of your app worth launching, and most of them fail for the same handful of reasons. Build one feature at a time. Rent payments, sign-in, the database and email instead of building them. Find out whether anyone wants it before you build. Give people one strong reason to choose you. Write tests from the beginning, split test what matters, and simplify anything users have to be taught. Build the way it spreads into the product, leave scaling until you have users, and charge from the first one.
An MVP is the smallest version of your app worth launching. These are the ten rules I build them by. None of them is clever, and every one of them is the kind of thing that only looks obvious after it has cost you a month.
1. Build one feature at a time
Pick the one thing the app has to do, build it until it works from start to finish, then start the next. Half-built features pile up risk: nothing can be tested, nothing can be shown to anyone, and each new one makes the last one harder to finish.
2. Don’t build anything you can rent
Payments, sign-in, the database and email have each been built better than you will build them in a weekend, and they cost pennies until you have real volume. Stripe, Clerk, Supabase and Resend do those four jobs. The only code worth writing yourself is the part that makes your app yours.
Stripe
Clerk
Supabase
Resend
3. Verify demand before you start building
Before you build, find out whether anyone wants it: a waiting list, a page people can pre-order from, or a run of conversations with the people who would use it. A few names on a list tell you more than months of guessing, and they cost nothing.
4. One strong reason beats ten nice-to-haves
People switch to a new app for one thing they could not get elsewhere, not for a longer feature list. Shazam launched with one button that named the song playing in the room, and that was enough. Find your one reason and make it impossible to miss.
5. Write tests from the beginning
A test is a small program that checks a part of your app still works. Write them as you build, not afterwards: each one costs minutes now and saves hours the day a change breaks something you had forgotten about. By the time the app is big enough to obviously need them, adding them is a project of its own.
$ npm test
✓ sign-up creates an account
✓ payment goes through
✓ booking email is sent
3 passed
6. Split test anything important
When a decision matters, show half your users one version and the other half another, and let the numbers decide. A split test, also called an A/B test, settles arguments about the sign-up screen, the price or the headline that would otherwise run for weeks.
7. If you have to teach users your UI, it’s too complicated
If people need a tutorial to use your app, the problem is the app. Watch someone try it without help, and simplify whatever they got stuck on until the tutorial has nothing left to explain.
8. Build distribution into the product
Decide at the start how one user leads to the next: an invitation, a result worth sharing, something made in the app that other people see. “Sent from my iPhone” put the product’s name under millions of emails. Growth bolted on after launch is advertising, and advertising is expensive.
9. Don’t think about scaling until you have users
Servers for a million people cost money and time you do not have, for users you do not have. Build for the first hundred. When they arrive and the app creaks, you will know exactly which part to fix, and you will have the revenue to fix it.
10. Charge from day one
A free app tells you that people will take something for nothing. A paid one tells you whether you have a business. Put a price on it from the first user: the people who pay are the ones whose opinions you need.
If you are still deciding what goes into the first version, Deciding What to Build covers that.