Scoping an MVP for a Mobile App: What to Build, Fake and Defer

Most MVP briefs I read aren’t minimum and aren’t viable. They’re version three of the product, written down before version one exists, with “MVP” on the cover page so the budget feels smaller.

I get why it happens. You’ve been thinking about this idea for months. Every feature feels essential because you can already picture the people using it. But an MVP isn’t a smaller version of your vision. It’s an experiment with a specific question attached, and the job of scoping is to make that experiment as cheap and as clear as possible.

Here’s how I help founders do that.

Start with the one job

Before we talk about screens, I ask one question: what is the single thing a user must be able to do for this app to be worth opening?

Not three things. One.

For a booking app, it might be “a customer can book and pay for a slot with a real provider.” For a habit tracker, “a user logs a habit and sees their streak tomorrow.” For a B2B field tool, “a technician records a job on site and the office sees it.”

Everything else gets judged against that sentence. Does sign-in with Apple help the user book a slot? Probably yes, because Apple requires it in some cases and it removes friction. Does a referral program help them book a slot? No. Not yet.

If you can’t write the one job in a sentence, that’s useful information too. It usually means there are two products hiding in the brief, and we need to pick which one to test first.

Must-have versus later

Once the one job is clear, I go through the feature list with the founder and sort every item into two buckets. I deliberately avoid a third “nice to have” bucket, because everything drifts into it and nothing drifts out.

Must-have means: without it, a real user can’t complete the one job, or the app gets rejected by a store, or you can’t legally operate. That last part matters. Account deletion, a privacy policy and the required payment rules aren’t optional just because you’re small.

Later means everything else. Later isn’t “never.” It’s a list we keep, and the first real users will tell us which items to pull forward. In my experience, a good chunk of that list quietly stops mattering once people are using the app, and a feature nobody predicted takes its place.

A few things that almost always land in “later”:

• User profiles beyond a name and a photo
• Social features: following, likes, comments, sharing to feeds
• In-app chat (a link to email or WhatsApp works for an MVP)
• Advanced search and filters
• Dark mode, multiple themes, heavy custom animation
• Gamification of any kind

Fake the back office

This is the part founders find most surprising. A lot of what looks like product is actually operations, and operations can be done by hand for the first few hundred users.

Some examples of what I suggest faking:

• Admin by spreadsheet. If you need to approve providers, edit listings or check orders, start with your database console or a shared spreadsheet connected to it. A proper admin panel is real work, and you’ll design it much better once you know which actions you do daily. (I go into the options in building an admin dashboard for your mobile app.)
• Manual onboarding. Instead of a ten-step self-serve flow for businesses, get on a call with them and set up their account yourself. You’ll learn more from those calls than from any analytics dashboard.
• Manual payouts. If you’re building a marketplace, you may be able to pay providers manually for the first weeks while you validate demand, before committing to a full split-payment setup. Check this with your payment provider and accountant first.
• Human matching. If your app “matches” people with something, a founder doing the matching by hand behind the scenes is a perfectly good algorithm for version one.

The user sees a clean app. Behind it is you, doing things that don’t scale. That’s fine. Doing them by hand is how you find out which ones are worth automating.

Cross-platform from day one

I’m a Flutter developer, so take this with that bias in mind, but I genuinely think launching on only one platform is a false saving for most MVPs.

Your early users don’t split neatly by phone. If you launch iOS-only, you’ll turn away a chunk of the people you most want to hear from, and you’ll get skewed feedback from the ones who stayed. With a cross-platform framework, the second platform costs a fraction of a separate native build. Most of the extra effort is store setup, testing on real devices and platform-specific details like permissions and push.

There are exceptions. If the app depends heavily on one platform’s hardware or APIs, start there. I cover how I make that call in Flutter vs React Native: how I advise clients.

Defer the expensive integrations

Integrations are where MVP budgets go to die. Each one comes with its own docs, edge cases, review rules and test accounts. For each one in the brief, I ask: can the one job happen without it, or with a simpler version?

Integration	MVP version	Later version
Payments	Single card checkout, or invoice outside the app	Subscriptions, marketplace splits, refunds in-app
Maps	Show an address and open the native maps app	Live tracking, routes, geofences
Notifications	A few transactional pushes	Segmented campaigns, in-app inbox
Analytics	One tool, a handful of key events	Funnels, attribution, A/B testing
Auth	Email plus Apple/Google sign-in	Teams, roles, invitations, SSO
Chat	Link out to email or a messaging app	Real-time in-app messaging

The left column is still a real, professional app. It just doesn’t pretend to be the finished product.

Set measurable launch goals

An MVP without a goal can’t succeed or fail. It just exists, and you end up arguing about whether it’s “working” based on gut feel.

Before we write code, I ask founders to write down what they’ll measure and what result would make them keep going. These are your numbers, based on your market, not mine. They usually look something like:

• How many people complete the one job in the first weeks
• How many come back and do it again
• Where people drop off in the main flow
• What users say when you talk to them (yes, actually talk to them)

Then we make sure the app can measure those things on launch day. That means analytics events on the key steps and crash reporting from the first build, not bolted on after the reviews start coming in. It’s a small amount of work that makes every later decision easier.

How to tell your MVP is really v3

Some warning signs I look for in a brief:

• More than one user type gets a full experience. Customer, provider and admin apps all polished at once.
• “And it should also…” appears more than a couple of times.
• The feature list was copied from a competitor that has been operating for years.
• Nothing is done manually. Every operational task has a screen.
• No one can say what would make it a failure.
• Launch keeps moving because one more feature has to be in.

If two or three of these sound familiar, we’re probably scoping a product, not an experiment. That’s not a disaster. It just means we should cut before we build, which is much cheaper than cutting after.

What a good MVP scope looks like

When we’re done, the scope fits on a page or two. It has the one job at the top, the must-have list, the “later” list, what’s being done by hand, which integrations are simplified, and the launch goals. It’s a document you could hand to any competent developer, and they’d build roughly the same thing.

From there, estimating gets much more honest. I explain how I turn a scope like that into numbers in how I estimate a mobile app project.

Takeaways

• Write the one job your MVP must do in a single sentence, and judge every feature against it.
• Sort features into “must-have” and “later.” Skip the “nice to have” bucket.
• Fake the back office: spreadsheets, manual onboarding and human matching are fine at the start.
• Launch on both iOS and Android if the budget allows; cross-platform makes the second one much cheaper.
• Ship simplified versions of payments, maps, chat and other heavy integrations first.
• Decide what success looks like before you build, and make sure the app can measure it.

If you have an idea and a brief that feels too big, send it my way and we’ll find the version worth building first.