MVP App Features: What to Build First, What to Cut

Which MVP app features should you build first?

Build the one job your app exists to do, and nothing that does not support it. Everything else waits until real users ask for it. An MVP (minimum viable product) is the smallest version of an app that lets a real person get real value and lets you learn whether you were right.

Most first versions fail the other way. They carry twenty features, take eight months, and then discover that users only wanted two of them. Below is the method we use when we scope a first version with a founder, plus a table you can copy.

If you want the short definition first, see our MVP glossary entry. If you are still weighing whether to build at all, our mobile app development service page shows how we scope and deliver a first release.

What is an MVP, and what is it not?

An MVP is a test of a business idea, not a cheap, broken app. "Minimum" is about the number of features. "Viable" means the features you keep must work well enough that someone would actually use them twice.

Three things an MVP is not:

• Version one of everything. It is version one of one thing.
• A prototype you throw away. Clickable mock-ups are useful earlier, but an MVP is real software people use with real data.
• An excuse for poor quality. A slow, buggy login loses users before they see your idea.

How do you choose the first features?

Score every feature idea against three questions. We ask them in this order because the first one removes most of the list.

1. What is the one job the app must do?

Write it as a sentence a customer would say: "I can book a home cleaner in under a minute." If a feature does not help that sentence come true on day one, it is not an MVP feature. It may be a good feature. It is just not first.

2. What is your riskiest assumption?

Every app rests on a guess that could be wrong. Maybe people will pay. Maybe they will upload their own photos. Maybe a restaurant will bother to update a menu. Find the guess that would kill the idea if false, and build the shortest path to testing it. Features that do not test that guess can wait.

3. What can be done by hand at first?

This is the question founders skip, and it saves the most money. If a human can do the step behind the scenes, do not build it yet. Approving new sellers by email, sending invoices from a spreadsheet, matching two people yourself: all fine for the first fifty users. You learn what the process really needs before you pay to automate it.

If you can answer all three, you have an MVP scope. If you cannot, you are not ready to pay for development, and a few days of thinking costs far less than a rebuild.

What does a must-have, later and never list look like?

Here is an illustrative example, not a client project. Imagine a simple app where local home cleaners list their availability and customers book them. The job: "A customer books a cleaner for a time that works."

Feature	Verdict	Why
Customer sign-up with phone or email	Must have	No booking without an account
Browse cleaners and available slots	Must have	This is the job
Book a slot and confirm	Must have	This is the job
Payment at booking	Must have	Tests the riskiest guess: will people pay through the app?
Push or WhatsApp booking reminder	Must have	Cheap, and no-shows kill the cleaner's trust
Cleaner approval	Manual at first	You check each cleaner by phone and add them by hand
Refunds and disputes	Manual at first	Handle by email until volume proves a need
Ratings and reviews	Later	Needs enough bookings to mean anything
In-app chat	Later	A phone call or WhatsApp covers it
Loyalty points and coupons	Later	Only matters once people come back
Admin analytics dashboard	Later	A simple export is enough at first
Social login with five providers	Never (for now)	One method is enough
AI cleaner recommendations	Never (for now)	No data to learn from yet

Notice that "manual at first" is a real category. It is neither "yes" nor "no", and it often holds the biggest savings.

How much does an MVP cost?

It depends on the number of screens, the integrations (payments, maps, messaging) and whether you need iOS, Android or both. We cover the cost drivers in detail in how much it costs to build a mobile app. A shorter feature list is the single biggest lever, because every feature adds design, build, testing and later maintenance.

If you are unsure about the technology, React Native vs Flutter explains how one codebase can serve both phone platforms. A web version first is sometimes the faster test, which is where our web development team comes in.

What mistakes make an MVP too big?

These are the ones we see most.

1. Building for the tenth customer instead of the first. Admin tools, roles and settings for a team you do not have yet.
2. Copying a mature competitor. Their feature list is the result of years of feedback you have not collected.
3. Treating "nice to have" as "must have". If the founder says "users will expect it", ask which user said that.
4. No decision on the one job. Every meeting adds a feature because nobody can say what to refuse.
5. Skipping the launch plan. An app with no first users is untested, however polished. Plan how the first twenty people will find it. The steps for getting it in stores are in our guide to launching on the App Store and Play Store.
6. Hiding behind polish. Perfect animations are not a test of your idea.

How do you know the MVP worked?

Decide the test before you launch, in writing. Otherwise every number looks like success. We suggest three measures and no more:

• Activation: of the people who install or sign up, how many complete the one job at least once?
• Repeat use: of those who completed it, how many come back and do it again without a prompt from you?
• The riskiest guess: did the thing you were afraid of happen? Did people pay, upload, invite?

Set your own targets from your own business maths. For example, work out how many repeat customers you need for the app to cover its running costs, then use that as the bar. We will not quote an industry "good" number, because it depends on your price, your market and your channel, and a borrowed benchmark is worse than none.

Also talk to users. Ten calls with people who used the app teach you more than a dashboard, especially in the first month. Then decide: keep going, change direction, or stop. All three are good outcomes if you learned them cheaply.

Talk to us

If you have an app idea and a rough feature list, send it over. We will tell you honestly what we would build first, what we would do by hand, and what we would drop. No pitch deck needed.

Book a 30-minute call when it suits you, or send the list by WhatsApp or email at hello@astrafolio.com. Expect an answer within 12 hours, Monday to Saturday (09:00 to 21:00 IST).

Frequently asked questions

How many features should an MVP have?

As few as it takes to do the one job well, which is often between three and seven. The number matters less than whether each feature is on the path to that job. If you cannot explain why a feature is needed for the first user, cut it.

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

Pick the place your first users already are. If they search on Google or use a laptop at work, a web app may test the idea faster. If the value depends on the camera, location or notifications, a mobile app makes sense. Sometimes the answer is a web version now and a phone app later.

Can I add features after launching the MVP?

Yes, and that is the plan. Good MVP code is written so new features can be added without a rewrite. The difference is that you add them in the order real users ask, not the order you guessed beforehand.

Is an MVP the same as a prototype?

No. A prototype shows how something might look or behave, often with fake data, and is used to test an idea before building. An MVP is working software that real people use, so it also tests whether the business works.

Who owns the code and accounts for my MVP?

You do. The code, app store accounts and hosting live in your own accounts, so you can move to another team at any time.