Scoping a first version: What to build first, and what to leave out
A first version is scoped well when it proves one thing to one kind of user, and leaves out everything that does not help prove it. Most first versions that disappoint were scoped as a small copy of the whole product instead of a test of one claim. This is how I scope a first version, from more than 40 products and MVPs launched over 14 years.
Start from the claim it has to prove
Write one sentence: who it is for, what they will do with it, and what result would tell you to keep going. “Finance teams will reconcile a month in an afternoon instead of a week.” Everything in the first version should help that sentence come true, or help you see that it does not.
Cut by what each feature proves
For every feature on the list, ask what it proves about the claim. Then sort the list the way a Product Diagnosis sorts a roadmap:
- Keep: the one job end to end, and whatever the user needs to trust it.
- Cut: what proves nothing yet. Settings, extra roles, a second integration, an admin panel a spreadsheet can stand in for.
- Change: features that are right in principle and too big for now. Ship the smallest version that still answers the question.
- Next: what comes after the claim holds, in order.
An example
Made up for this guide, not a client: the finance tool from the claim above. The founder’s first list had eight lines.
| Feature | Call | Why |
|---|---|---|
| Import bank statements and the ledger | Keep | The claim fails without it |
| Match transactions and flag the rest | Keep | This is the afternoon instead of the week |
| Sign-in for a small team, with a record of who changed what | Keep | Finance teams will not use it otherwise |
| Roles and approval chains | Change | One reviewer role is enough to test the claim |
| Integrations with three accounting tools | Change | One: the tool the pilot customers use |
| Dashboards and reports | Cut | A spreadsheet export answers the question for now |
| Settings, themes and notifications | Cut | They prove nothing yet |
| A mobile app | Next | After the claim holds on the desktop |
Three lines stay as they are, two shrink, and the first version tests one sentence.
What it needs even when it is small
- The one core flow, designed end to end with its empty, loading and error states.
- Sign-in and data that are safe to put real users on.
- The steps the rules require, like identity checks in fintech, designed so they cost as little as allowed.
- A way to learn: the few events that show whether people reach the result.
- A design system, even a small one, so the second version does not start again.
Scope it in writing
One page, agreed before anything is built: the claim, the users, the one job, the flows in it, what is out, the date, and the price. It is the document people point to when a new idea arrives in week three.
Two first versions from my work
- Equi, a digital family office, went from zero to MVP with KYC and AML onboarding inside it, because nobody could invest without it. Onboarding time dropped by 40%.
- Deva, an AI agent platform, went from the first concept to a beta in 15 months through several pivots. The screens were rebuilt each time; the objects under them, the agent, its sources and its permissions, changed much less, which is why they were defined first. More: Designing agent products.
Prototype, AI tools or a build
If the question is whether anyone wants it, a prototype made with an AI tool can answer it in days. If people will put real data or money in it, it needs a real build. When a prototype that worked in a demo breaks with real users, the first question is who fixes it: Developer or designer for an AI-built app.
Questions founders ask
What should an MVP include?
The one job your claim depends on, end to end, plus what users need to trust it: safe sign-in and data, the steps the rules require, and a way to see whether it works.
How long should an MVP take?
As long as the one job takes to build well. If the plan runs to many months, the scope is probably a small copy of the whole product.
Should I build my MVP with Lovable or Cursor?
To find out whether people want it, often yes. To put real users and money on it, it needs to be built properly, which can start from the prototype.
How much does it cost to design and build an MVP with you?
From $8,000, with the scoping week counted in. See design and build.
About to build a first version?
Send a few lines about the idea and who it is for. I’ll tell you what I would put in it, and what I would leave out.