How to Scope an MVP: What to Build First (and What to Leave Out)

To scope an MVP, pick one type of user, one problem and one job they need done, and build only what lets that user finish the job from start to end. Sort every other idea into Must, Should, Could and Won't-have-this-time, use proven services for commodity parts such as payments and sign-in, and decide before launch which numbers will tell you whether it worked.

This guide is for non-technical founders in the UK, the US and Canada who have an idea, a budget and a list of features that keeps growing.

What is an MVP, and what is it not?

An MVP is the first version of a product that tests your riskiest assumption with real users. Eric Ries, who popularised the term, defines it as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (Startup Lessons Learned, accessed Oct 2026).

In the same post he warns that the MVP, "despite the name, is not about creating minimal products". The aim is learning, not a small feature count. So an MVP is:

• Not a cheap version of the full product. Every feature a user touches still has to work, be secure and handle their data lawfully.
• Not a demo. A clickable prototype tests a design, but nobody can do real work in it, so it can't tell you whether people will keep using the product.

Where should MVP scope start?

Start with one user, one problem and one job, written as a single sentence. Everything in the first release must serve that sentence.

• One user. Pick the person whose behaviour has to change for the business to work. A marketplace needs both sides, but scope around the side that is harder to win.
• One problem. Name what it costs that user today, in time, money or risk. "Builders lose hours chasing supplier quotes by phone" is a problem. "Construction is inefficient" is not.
• One job. Write what the user must be able to do, from start to finish. For example: "A site manager can request prices for a materials list from three suppliers and compare the replies in one place."

If you cannot write that sentence, go back to customer conversations first; our step-by-step guide to building an app covers validation before any code is written.

How do you turn the job into user stories?

Break the job into user stories: short descriptions of what someone needs to do and why. Mountain Goat Software gives the common template: "As a [type of user], I [need/want/am required] to [do something], so that [reason or benefit]" (Mountain Goat Software, accessed Oct 2026).

For the quote example above, the core stories might be:

1. As a site manager, I need to create a materials list, so that suppliers price the same thing.
2. As a site manager, I need to send that list to several suppliers at once, so that I don't have to phone each one.
3. As a supplier, I need to reply with prices without creating an account, so that answering takes minutes.
4. As a site manager, I need to see all replies side by side, so that I can choose quickly.

Give each story acceptance criteria, the details that show whether it is done correctly, such as "Replies show unit price, delivery date and VAT". Hidden scope surfaces here, so write them before anyone estimates.

How do you use MoSCoW to decide what goes in?

MoSCoW sorts every story into four groups. The Agile Business Consortium, which maintains the method as part of DSDM, defines them as follows (Agile Business Consortium, accessed Oct 2026):

• Must Have: the "Minimum Usable SubseT" the project guarantees to deliver. Tests include "No point in delivering on target date without this", "Not legal without it" and "Unsafe without it".
• Should Have: "Important but not vital". Painful to leave out, but the solution still works.
• Could Have: "Wanted or desirable but less important", with less impact if left out.
• Won't Have this time: agreed not to be delivered in this timeframe.

The Consortium recommends "typically no more than 60% Must Have effort" and a contingency pool of "typically around 20% Could Have effort". If almost everything on your list is a Must, the list has not been prioritised yet.

The "Won't have this time" list matters as much as the Must list. Writing an idea down as deferred, rather than deleting it, makes cutting it much easier to agree.

Which features can usually wait?

These five features make sense in a mature product but are rarely needed to answer the first question.

Admin panels

Someone has to approve users, fix records and issue refunds, so the MVP needs a back office. It does not need dashboards, charts or bulk tools. Build the few screens your team will use every day, and handle rare tasks by hand until they become frequent.

User roles and permissions

Each role multiplies screens, permission rules and test cases. Build Hive, a construction platform we built for a UK company, has five isolated roles (owner, admin, manager, worker and supplier) because it serves a company already running procurement across all of those people. A first version of a new idea can usually start with two roles: the user and your own admin. Build Hive also shows a useful cut for a secondary user: suppliers submit quotes through a magic-link portal, which keeps sign-up friction away from people who only need to send a price.

Payments

If charging is part of what you are testing, payment is a Must. If it is not, you can often invoice the first customers by hand or send a hosted payment link.

Notifications

Send email for events the user cannot miss, such as a booking confirmed or a quote received. Push notifications, SMS, digests and preference centres can usually wait until you know which messages people act on.

Analytics

Measure the core job from day one, but skip the reporting suite. Track one event for each step of the job and review the numbers weekly.

GOYOG, a construction services marketplace we are building in Hyderabad, shows the same principle at a larger scale. Its product has four ways to book a job; three are in phase 1, and the fourth, Daily Hire, is held back for phase 2. Phase 1 is planned at about ten weeks from kick-off to launch.

Should you build or buy sign-in, payments, email and maps?

Buy the parts every product needs and that specialists do better, and build the part that makes your product different. For an MVP, that usually means buying all four of these.

• Sign-in. Use managed authentication rather than custom login code. The UK's Information Commissioner's Office says not to store passwords in plaintext, to use a password-hashing algorithm with a salt, and to "implement two-factor or multifactor authentication wherever it is possible to do so" (ICO, accessed Oct 2026). A managed service gives you those controls without building them. We build on AWS (Amazon Web Services), where Amazon Cognito provides managed sign-in.
• Payments. Use an established payment provider such as Stripe. Anyone who processes, transmits or stores card data must comply with PCI DSS. Stripe says that its low-risk integrations send card details directly to Stripe "without it passing through your servers, reducing your PCI obligations" (Stripe, accessed Oct 2026). Build Hive uses Stripe for subscriptions, a 14-day trial, checkout and a customer portal. If you plan an iPhone app, note that Apple requires in-app purchase for digital features and subscriptions, but requires other methods, such as Apple Pay or card entry, for physical goods and services used outside the app (App Store Review Guidelines 3.1.1 and 3.1.3(e), accessed Oct 2026).
• Email. Send transactional email through a dedicated sending service, such as Amazon SES on AWS, rather than your own mail server. Gmail requires every sender to set up SPF or DKIM, and anyone sending more than 5,000 messages a day to Gmail to set up SPF, DKIM and DMARC (Gmail Help, accessed Oct 2026). Without them, confirmation emails can land in spam.
• Maps and addresses. Use a mapping platform rather than your own map data. Google Maps Platform charges by usage, with a monthly free allowance for each product (Google Maps Platform, accessed Oct 2026), so model usage before launch.

What you build is the workflow behind your one job, such as the matching, quoting or scheduling your customers cannot get elsewhere. That is where a full-stack team should spend its time.

What security and data protection belongs in an MVP?

All of it that applies to the data you collect. A smaller product is not exempt from data protection law, and the cheapest way to comply is to collect less.

• UK and EU. Under UK GDPR, data protection by design and by default is a legal requirement. The ICO says you must "limit your use of personal information to what is necessary to achieve each specific purpose" (ICO, accessed Oct 2026). The EU GDPR contains the same principle in Article 25.
• Canada. PIPEDA's limiting-collection principle says to "collect only the personal information your organization needs to fulfill a legitimate identified purpose" (Office of the Privacy Commissioner of Canada, accessed Oct 2026).
• US. There is no single federal privacy law for most products. California's CCPA applies to for-profit businesses that meet set thresholds, such as on annual revenue or the number of California residents whose data they handle (California Privacy Protection Agency, accessed Oct 2026), and other states have their own laws.

In practice, every field on every form should have a purpose you can state in the scope document. Add encryption in transit, server-side permission checks on every request, backups and access logs, which belong in the first release, not a later one.

This is general information, not legal advice. Confirm your obligations with a qualified adviser.

What should an MVP scope document include?

One page that the founder, designer and developers all sign off. Use this structure:

1. The job sentence: one user, one problem, one job.
2. The riskiest assumption: what must be true for the business to work, such as "suppliers will reply through a link without phoning".
3. User stories with acceptance criteria, grouped as Must, Should, Could and Won't have this time.
4. Roles: who can do what, ideally no more than two or three.
5. Bought services: sign-in, payments, email and maps, and the account owner for each.
6. Data inventory: each piece of personal data collected, why, where it is stored and for how long.
7. Platforms: web, iPhone, Android, or a combination, and why.
8. Success measures: the numbers you will review, with the thresholds agreed in advance.
9. Out of scope: the deferred list, written down.
10. Change rule: how a new request gets in, and what comes out to make room.

How do you know whether the MVP worked?

Agree before launch what result would make you continue, change direction or stop. The Lean Startup describes the core loop as turning "ideas into products, measure how customers respond, and then learn whether to pivot or persevere" (The Lean Startup, accessed Oct 2026).

Measure behaviour, not opinions:

• Activation: the share of sign-ups who complete the core job once.
• Repeat use: the share who come back and do it again within a period that fits the job, such as weekly for site quotes.
• Willingness to pay: pre-orders, paid pilots or conversion from trial to paid.
• Reasons for drop-off, from five or six short calls with users who stopped.

Sign-ups alone are not a result. A hundred sign-ups with no repeat use is a clear, useful answer.

What traps sink MVP scope?

• Building for investors instead of users. Features added to impress in a pitch, such as dashboards, AI add-ons or a long role list, spend the budget without testing the riskiest assumption. A narrow product that answers that question gives you evidence to show; a broad one that answers nothing does not.
• Feature creep. Each request seems small, and together they move the launch by months. Apply the change rule: anything new enters as a Could or a Won't unless something of similar size comes out.
• Skipping onboarding. If a new user cannot reach a first useful result without help, your activation numbers measure the onboarding, not the product. Scope empty states, first-use guidance and invitations as Musts.
• Forgetting operations. Refunds, disputes, account deletion and support requests happen in week one. Decide who handles each and which screen they use.

A step-by-step plan for scoping your MVP

1. Write the job sentence and the riskiest assumption.
2. List every feature idea, then turn the ones that serve the job into user stories.
3. Add acceptance criteria to each story.
4. Sort the stories with MoSCoW, keeping Musts to no more than about 60% of the effort.
5. Mark what to buy: sign-in, payments, email and maps, with hosting on AWS.
6. List the personal data and check each item against its purpose.
7. Define success measures and the thresholds that trigger a decision.
8. Fill in the scope document and get it signed off.
9. Plan the build in short cycles with a working version every week or two, and revisit the deferred list only after launch.

For a focused first product, scoping usually takes one to two weeks. That is a planning range, not a guarantee.

Frequently asked questions

What is the difference between an MVP and a prototype?

A prototype shows how the product would work, usually as clickable screens with no real data. An MVP is working software that real users rely on to do the job, so it can measure whether they keep using it.

How many features should an MVP have?

There is no right number. Include the stories needed to finish one job from start to end, and keep Must Have work to no more than about 60% of the effort, as the Agile Business Consortium recommends.

Should an MVP be a web app or a mobile app?

Choose the platform your users already use for this job. Many business MVPs start as a responsive web app; an app makes sense when the job happens on site, often or with the camera and GPS.

Can an MVP skip security and privacy work?

No. UK GDPR, PIPEDA and US state laws apply to the data you collect, whatever the size of the product. Collecting less is the simplest way to reduce the work.

What does MoSCoW stand for?

Must Have, Should Have, Could Have and Won't Have this time. The Agile Business Consortium describes the Musts as the "Minimum Usable SubseT" the project guarantees to deliver.

About the author

Arjun Raj is the founder of Digital Architect, a web, app and digital marketing studio founded in 2023 and headquartered in LB Nagar, Hyderabad, with a studio in Bengaluru. The team builds apps and platforms for clients across India, the US, Canada and the UK. Arjun holds a B.Tech in Computer Science and Engineering, specialising in cybersecurity, from IIT Guwahati. More about Arjun

Scoping a first version? Send us the job sentence and your feature list, and we will tell you what we would build first and what we would leave for later. Talk to Digital Architect.