An MVP is built in seven steps: confirm the problem is real, define the one job the product does, rank features with a strict rule, check the list against what a release actually needs, decide who builds it, build it in reviewable increments, then launch to a small group and measure. Steps one to four need no code and decide most of the outcome.
Step 1: Validate the problem before writing code
An MVP tests whether a solution works for people who have a problem. It is a poor tool for discovering whether the problem exists, because it takes months and tens of thousands of dollars to return an answer you could get in two weeks.
Cheaper tests, in rough order of effort:
- Problem interviews. Ten to fifteen conversations with people in the target group. Ask what they do today, what it costs them and what they have already tried. Do not pitch. Past behavior is evidence; "I would use that" is not.
- A landing page with one call to action. Join a waitlist, book a call, or pre-order. Measures whether the promise is interesting enough to act on.
- A concierge version. Deliver the outcome by hand using email, spreadsheets and existing tools for a few customers. Slow and unscalable on purpose. You learn the real workflow and whether anyone pays.
- A no-code version. Reasonable when the workflow is forms, lists and notifications.
You are ready to build when you can name specific people who have the problem, describe how they handle it today, and point to some behavior (time given, money paid, a signed letter of intent) that shows they want it solved. If a technical question is the main uncertainty instead, you may need a proof of concept first. The differences are covered in MVP vs prototype vs proof of concept.
Step 2: Define the core job
Write one sentence in this form:
[Specific user] can [do one thing] so that [outcome they care about].
For example: an independent dog groomer can take online bookings with a deposit, so that no-shows stop costing them money.
Then write the belief the MVP is testing and what result would count as a pass: groomers will connect their calendar and send the booking link to clients within their first week. This sentence and this belief are the reference for every scope argument that follows. A feature either serves them or waits.
Choose one user type. Products with two sides still have one side that is harder to win. Build for that side, and serve the other with the least software you can get away with.
Step 3: Map the journey
List every step the user takes from first arriving to getting the outcome, including the unglamorous ones: sign up, confirm email, set up, do the core action, get the result, get notified, come back. Then do the same for whoever operates the product, which at this stage is you. Operators need to see users, fix data, issue refunds and answer support requests.
This map is where forgotten features surface. It is also the raw material for the feature list.
Step 4: Prioritize with must, should and later
Put every candidate feature into one of three columns.
| Column | Rule | What happens to it |
|---|---|---|
| Must | Without it the user cannot complete the core job, or you cannot tell whether they did, or you cannot legally or safely operate | In the first release. This is the fixed scope. |
| Should | Clearly improves the core job, and there is a tolerable workaround without it | Ranked. Built only if time remains, otherwise first in line after launch. |
| Later | Everything else, however good the idea | Written down so it is not lost, then ignored until users ask for it. |
The removal test
For each item in the must column, ask three questions:
- If we removed this, could a user still get the main benefit?
- If we removed this, could we still tell whether they got it?
- Could a person do this by hand for the first fifty users?
Two yes answers to the first two questions move the feature out of must. A yes to the third means it can be replaced by a manual process for now. Founders usually find that a third to a half of their original must list does not survive.
Worked example: the grooming booking product
| Feature | Column | Reasoning |
|---|---|---|
| Groomer sets services, prices and working hours | Must | No booking is possible without it |
| Public booking page with available slots | Must | This is the core job |
| Deposit payment at booking | Must | The outcome is fewer no-shows; the deposit is the mechanism |
| Confirmation and reminder emails | Must | Part of completing the job for both sides |
| Event tracking on setup, link shared, booking made | Must | Without it the belief cannot be tested |
| Two-way calendar sync | Should | Valuable; workaround is a one-way calendar feed |
| SMS reminders | Should | Email covers it at first |
| Client mobile app | Later | Clients book a few times a year; a web page is enough |
| Multi-staff salons | Later | Different user, different product. Target independents first. |
| Reviews, loyalty points, marketplace search | Later | None of it tests the belief |
| Rescheduling by the client | Manual | Client emails the groomer; groomer edits the booking |
Step 5: Check the list against a first-release feature checklist
Feature lists written by founders describe what users see. A release also needs things nobody asks for until they are missing. Go through this list and mark each line as needed, not needed, or handled manually.
User-facing basics
- Sign up, log in, log out, password reset (or passwordless login)
- Email verification where accounts hold anything of value
- The core workflow, complete from start to outcome
- Empty states, loading states and readable error messages
- Transactional emails: welcome, confirmation, receipt
- Basic profile and settings, including a way to delete the account (required by both app stores for apps with accounts)
- Works on a phone-sized screen, even if the product is web only
Money, if you charge
- Checkout or subscription through a payment provider, never card handling of your own
- Receipts or invoices, failed-payment handling, cancellation
- A way for you to refund or comp a user
Operator basics
- An admin view: list and search users, see their key data, deactivate an account
- A way to correct data without asking an engineer to run a database query
- A support contact path and someone who reads it
Measurement
- Product analytics events on each step of the core journey
- Error monitoring, so you hear about crashes before users tell you
- A simple way to see signups, activations and returns per week
Legal and release
- Terms of service and privacy policy that match what the product really collects
- Cookie or tracking consent where your audience's law requires it
- Separate staging and production environments, database backups, a custom domain with working email delivery
- For apps: store listings, screenshots, privacy declarations, and developer accounts in your company's name
Usually safe to leave out of a first release
- Social login, unless your users expect it and passwords are a real barrier
- Referral programs, gamification, badges
- In-app chat, when email does the job
- Multiple languages and currencies, unless the first market requires them
- Dark mode, custom themes, onboarding tours
- Native mobile apps, when the core job works in a browser
- Role and permission systems more detailed than "user" and "admin"
Step 6: Decide who builds it
With a ranked list in hand you can make this decision on evidence. The realistic options are a no-code build you assemble yourself, a freelancer, a studio or agency, or a technical co-founder or first hire. The right one depends on how complex the must column is, how much you can spend, and how much project management you can do yourself.
The trade-offs are long enough to have their own pages: building without a technical co-founder compares all the routes for a non-technical founder, and how to choose an MVP development company covers vendor evaluation. Whoever builds it, the technology should be mainstream and easy to hire for. Our guide to choosing an MVP tech stack explains the reasoning.
Step 7: Build, launch, measure
Write the scope down
Turn the must column into a scope document: each feature described as what the user can do, with acceptance criteria that say how you will both know it is done. This document is what a fixed price and a timeline attach to. It also ends most disputes before they start.
Review a prototype before engineering
Clickable screen designs for the core journey, put in front of three to five target users. Watching someone fail to find the main button costs an afternoon at this stage and a sprint later.
Build in increments you can open
Ask for a staging link or test build early, and use it every week. Build the riskiest part first, whether that is an integration, a matching algorithm or an AI output that has to be good enough. Keep a change log: every new idea goes into should or later unless you consciously trade something out. Typical durations for each phase are in the MVP timeline guide, and budget ranges in the cost guide.
Launch small first
Release to ten to thirty invited users before any public announcement. Onboard them personally. You will find the problems that testing missed while the audience is still forgiving.
Measure against the belief you wrote down
| Question | Signal to watch |
|---|---|
| Do people start? | Share of signups who complete setup |
| Do they reach the value? | Share who complete the core action at least once |
| Do they come back? | Repeat use in weeks two to four, at whatever frequency is natural for the job |
| Will they pay? | Conversions, or at minimum a direct answer when asked for money |
| Why not? | Conversations with users who stopped. Analytics shows where; only people tell you why. |
With a few dozen users, percentages are noisy. Treat the numbers as prompts for conversations, not as proof. Then decide: keep going and pull items from the should column, change the audience or the core job, or stop. All three are legitimate results of a test that cost months instead of years.
Process mistakes that cost the most
- Starting at step 6. Choosing a developer before the core job and the must column exist means paying engineering rates for product thinking.
- Two audiences at once. Every feature gets argued twice and neither group is served well.
- No measurement in the must column. The product launches and nobody can say whether it worked.
- Treating the later column as a promise. It is a parking area. Most of it should never be built.
- Spending the whole budget on the build. The first release is the start of learning. Hold money back for what you learn.
If you would like a second opinion on a feature list, this scoping work is the first stage of BBR's MVP development service.