What to build first in an MVP

The hardest part of a first version is not building it. It is leaving things out. Every founder we have worked with arrived with more ideas than any first version could hold, and every one of them was right that those ideas mattered. The question is never "is this a good feature?" It is "does this help prove the thing we need to prove first?"

Here is how to answer that, in four steps you can do on paper before any build starts.

1. Write down what the first version must prove

An MVP is an experiment with a product attached. Before listing features, finish this sentence: "If the first version works, we will know that ___."

Some honest examples:

• "…clinics will let patients book themselves, and patients will do it."
• "…small distributors will pay a monthly fee to see where their vans are."
• "…people will upload their own data rather than typing it in."

If you cannot finish the sentence, the first version has no target and will grow until the money runs out. If you can, every feature decision gets easier: does it serve the sentence, or not?

2. Pick one user and one job

Choose the single kind of user whose behaviour proves the sentence, and the single job they do. Not "customers and staff and admins". One.

Then write the job as a path: open the app, do this, then this, then done. Every screen on that path is in. Everything else is a candidate for cutting.

A booking product's first path might be: see available times, pick one, enter a name and phone number, get a confirmation. The clinic's side, at first, can be an email. It is not elegant. It proves the sentence.

3. Cut, but not these

Most things can be cut from a first version and added later without damage: polished design, settings screens, multiple languages, reports, roles and permissions, social login, in-app chat. Cut freely.

Three things cannot be cut, because fixing them later means rebuilding:

• The records. How bookings, customers, orders or jobs are stored, and how they relate. Changing this after real data exists is painful. Get it right at the size you will need, not the size you have.
• Accounts and ownership. The store accounts, the hosting, the domain and the code must be in your company's name from day one. Moving them later is slow and sometimes impossible.
• A way to release. A repeatable process for getting a new version to users. Without it, every fix after launch is a fire drill.

4. Buy the parts that are not your product

Sign-in, password reset, payments, sending email and SMS, maps, file storage: these are solved problems with good paid services behind them. Using them is faster and safer than building your own, and nobody will choose your product because of its password-reset screen.

The parts you should build yourself are the ones in your sentence from step one. That is where the product is.

What the second version should wait for

Decide before launch what you will measure. Sign-ups? Completed bookings? Users who come back in week two? Pick the one number that the sentence depends on, and make sure the first version records it.

Then set a date to look at that number. On that date, the second version writes itself: fix what stopped people finishing the job, and add the next thing the people who did finish are asking for. Everything you cut in step three is still on the list, and now you know which of it matters.

A one-page brief for your developer

1. The sentence: what the first version must prove.
2. The one user and the one job, as a path of steps.
3. The cut list, so nobody adds it back by accident.
4. The three things that will not be cut: records, ownership, release.
5. The number you will measure, and the date you will look at it.

Bring this to the first conversation with any developer. If they start by proposing more, ask them why. If they start by asking what you are trying to prove, you have found the right one.

For scale: our Lean MVP package is built around exactly this kind of brief. It covers one main workflow, about 5 to 8 screens, and one type of user with simple sign-in. Payments, live tracking, more roles and connections to other services are added only when the plan says so.