Which MVP Features Should You Build First? A Must-Have vs Nice-to-Have Scoring Sheet for Non-Technical Founders

Why a scoring sheet beats a gut feeling

Lists like MoSCoW (must, should, could, won't) are useful, but they still ask you to sort by feeling. A founder who loves an idea will put half of it in "must". A scoring sheet asks the same five questions about every feature. A chat feature and a payment screen get judged by the same rules. When you're done, the numbers do the arguing, not your attachment to the idea. It also gives you something concrete to show an agency, a co-founder or an investor: "here is what v1 does, and here is why the rest waits."

The 5 questions of the MVP scoring sheet

Score each feature from 0 to 2 on each question. The maximum is 10.

• 1. Core result. Does the user need this to get the main thing your app promises? 0 points: no. 1 point: it makes it easier. 2 points: they can't get the result without it.
• 2. Money. Does it help you get paid or prove someone will pay? 0 points: no link to revenue. 1 point: indirect link. 2 points: it is how you charge.
• 3. Can't fake it. Can you do this by hand for your first users? 0 points: easy to do by hand. 1 point: painful but possible. 2 points: impossible by hand.
• 4. Required to launch. Will users, the law or the app stores refuse the app without it? 0 points: no. 1 point: users would complain. 2 points: it blocks launch.
• 5. Riskiest guess. Does it test the assumption most likely to kill your idea? 0 points: no. 1 point: partly. 2 points: yes, directly.

How to read the score

Add up the five scores for each feature, then sort:

• 8 to 10: must-have. Goes into v1, no debate.
• 5 to 7: cut it down. Keep the smallest version of it. A "share" feature becomes a copy-link button. Automated reports become one export.
• 0 to 4: nice-to-have. Write it on the v2 list and stop thinking about it.

One override rule

If a feature scores 2 on question 4, it goes in, whatever the total. Some things are not optional. For example, Apple's App Review Guidelines (section 5.1.1(v)) say: "If your app supports account creation, you must also offer account deletion within the app." Nobody gets excited about a "delete account" button, but you can't launch on iOS without it.

A worked example: a booking app for dog walkers

Here is the sheet filled in for a made-up idea: an app where independent dog walkers manage bookings and get paid by their clients. Scores are given in this order: core, money, can't fake, required, risk.

• Walker sign-up and login. Scores: 2, 1, 2, 2, 0. Total 7. Decision: override, in v1.
• Clients book a walk slot. Scores: 2, 1, 2, 0, 2. Total 7. Decision: cut down to one slot type.
• Card payment at booking. Scores: 1, 2, 2, 0, 2. Total 7. Decision: cut down to one price per walk.
• Walk reminders by push. Scores: 1, 0, 1, 0, 0. Total 2. Decision: v2.
• Live GPS tracking of the walk. Scores: 1, 0, 2, 0, 1. Total 4. Decision: v2.
• In-app chat. Scores: 1, 0, 0, 0, 0. Total 1. Decision: v2, use text messages.
• Reviews and ratings. Scores: 0, 0, 1, 0, 0. Total 1. Decision: v2.
• Walker earnings dashboard. Scores: 1, 1, 0, 0, 0. Total 2. Decision: v2, send a weekly summary by hand.
• Delete account. Scores: 0, 0, 2, 2, 0. Total 4. Decision: override, in v1.

What the example tells the founder

The riskiest guess here is "will clients pay through the app instead of cash?" Payment scores 2 on risk, so it moves to the front of the build, not the end. Three more lessons from the sheet:

• v1 is four things: login, booking, payment and account deletion. That's a launchable app.
• GPS tracking felt like the "wow" feature, but it doesn't test whether walkers will pay or clients will book. It waits.
• Chat scores 1 because walkers and clients already text each other. Building it would cost weeks and teach you nothing.

How to fill in your own sheet in one hour

Follow these seven steps. If you want to know what each type of feature tends to involve, our feature costs guides break them down one by one. Not sure your scores are right? Book a call and bring your sheet. 30 minutes, free.

• 1. Write every feature you've imagined in one column. Don't filter yet. The list is usually longer than you thought.
• 2. Write your app's main promise in one sentence above the table. Example: "Dog walkers get booked and paid without chasing clients." Score question 1 against this sentence.
• 3. Write your riskiest guess in one sentence. Example: "Clients will pay by card in an app." Score question 5 against this one.
• 4. Score each feature on its own, in under a minute. If you hesitate between 1 and 2, pick 1.
• 5. Apply the override rule to anything that blocks launch.
• 6. Cut down every 5 to 7. Ask: "what's the smallest version that still works?"
• 7. Read your v1 out loud. If it takes more than one breath, you probably kept too much.

The features founders score too high

Some features keep showing up in "must-have" lists when they rarely belong in v1. And the ones founders score too low: login, account deletion, payment, and the one screen that delivers the main result. They're boring, and they are the app.

• Admin dashboards. For your first users, you can often look at the data directly or use a simple export.
• Social features like feeds, likes and followers. They need lots of users to be useful, and you don't have them yet.
• Notifications for everything. One or two key alerts are enough at launch.
• Multiple user roles and permissions. Start with one role if you can.
• AI features added "because everyone has one." Score them like any other feature. If they don't touch the core result or the riskiest guess, they wait.

How your score turns into a fixed price

A short, scored list is what lets you get a firm price before any code is written. Our MVP Development package builds that focused v1 for the web, iOS and Android. You can see what focused first versions look like on our projects page. Ready to turn your scores into a launch plan? Book a call. 30 minutes, free. Here is what you get:

• Fixed at $3,460. Fixed quote given before we start.
• Delivered in about 20 days.
• Progress shown every week.
• Design included.
• Code 100% yours, on your GitHub.
• 2 weeks of fixes after launch.

What is the difference between a must-have and a nice-to-have MVP feature?

A must-have feature is one your user needs to get the main result of your app, or one that blocks launch if it's missing. A nice-to-have improves the experience, but the app still works and still tests your idea without it.

How many features should an MVP have?

There's no fixed number. A good test: your v1 should deliver one main result to one type of user, and you should be able to describe it in one sentence. If your scored list keeps more than a handful of must-haves, look again at the 5 to 7 scores and cut them down.

What should I build first when I build an MVP?

Build the feature that tests your riskiest guess, plus whatever you need around it to launch: login, the core screen and payment if you charge. When you build the riskiest part first, you find out early whether the idea holds.

Can I add nice-to-have features after launch?

Yes, and that's the point. Your v2 list is a backlog, not a loss. Once real users are in the app, what they do tells you which nice-to-haves matter. Our continuous support service is there for that next stage.

Do I need to be technical to use this scoring sheet?

No. Every question is about your user, your money or your launch, not about code. You only need your feature list, your app's main promise in one sentence and your riskiest guess. Want to go through your scored list with us? Book a call.