MVP mobile app development is mostly a decision about what to leave out.
Writing the code for a first version has never been easier. MVP mobile app development goes wrong earlier than that, in the argument about scope. Sign-in, roles, a staff dashboard and search all get added before one stranger has opened the app. A mobile app MVP exists to answer a question. A version that answers nothing is not minimal, it is just unfinished. If you are earlier than this stage, start from the broader app development guide.
This page covers how to choose the one job, which decisions are expensive to undo later, what a generated build actually gives you on day one, and the store rules that decide when real people can install it.
See what each addition costsThe short version
A minimum viable product app is not a smaller app. It is one job, finished.
The test is not how many features you removed. It is whether someone can start a real task in your app and finish it without you sitting next to them. One complete path beats four half paths every time, because only the complete one produces a fact about whether people want this.
Two things then set your calendar, and neither of them is code. What you store, because the shape of your records is the one thing you cannot change later without moving every record that exists. And how the build reaches a phone that is not yours. Apple and Google both have rules about that, and one of Google's is a fixed two week wait.
Pick the one job, then defend it
Start from a task, not a feature list. Someone has a problem at a particular moment: a coach needs to record what happened at training before she forgets it, a landlord needs a photo of a meter reading attached to the right flat. Write that sentence down. The first version is the shortest path from opening the app to that sentence being true.
Then write the second list, the one that gets skipped: everything the first list quietly implies. A photo needs storage, a permission prompt with a written reason, and a decision about what happens on a bad connection. Two kinds of user need a way to tell them apart. Every item on the visible list drags two or three invisible ones behind it. That ratio is why MVP timelines slip, not any single feature.
The useful discipline is to date the cuts instead of arguing about them. Search, filters, an export, a staff dashboard: none of these are wrong, they are just later. Keep them on a list with the question each one answers, and promote one when a real user asks for it twice.
Try it
What each addition to the first version drags with it
Tick what you want in version one, on top of the single job itself. The work nobody puts in the estimate is listed underneath.
0 of 6 added
One job, finished. That is a first version you can hand to a stranger this month.
What you store is the decision you cannot cheaply undo
Screens are cheap to change. Records are not. If version one stores a job with a customer name typed into it, and six weeks later a customer turns out to have three sites and two contacts, you are not editing a screen. You are migrating every row that exists, plus every screen that reads one, plus the phones that already hold a copy.
So spend an hour on the shape before you spend a week on the screens. Name the things your app really has, then the relationships between them: a job belongs to a site, a site belongs to a customer, a photo belongs to a job. That is most of what mobile app database design is for, and it is the cheapest hour in the project.
Two fields are worth adding on day one even though nothing reads them yet. A created timestamp on every record, because you will want to know when something happened and you cannot backfill it afterwards. And a deleted flag instead of a real delete, because the first support message you get will be about something that somebody removed by accident.
Sign-in and roles are where an MVP quietly doubles
Accounts feel like table stakes, so they get built first. Ask what actually breaks without them. If the app is useful to one person on one phone, a login adds a password reset flow, a session to keep alive, an email sender and a support queue. It answers no product question at all.
Apple has a rule here that is worth reading before you plan the work. Guideline 5.1.1(v) says that if your app does not include significant account-based features, let people use it without a login. It adds that if your app supports account creation, you must also offer account deletion within the app. Sign-up is therefore not one feature. It is sign-up, deletion, and the screens in between.
The moment two kinds of user exist, every screen needs a rule about who sees it and who can change it. That is a larger job than it looks, and it is the subject of app user roles permissions. For a first version the honest move is usually one role, then a split when somebody is genuinely harmed by sharing.
Real testers are gated by the stores, not by your code
This is the part most MVP plans miss. A finished build is not a tested product. Getting it onto phones that do not belong to you runs through Apple and Google, and both of them add calendar time you cannot compress by working harder.
On iOS, TestFlight takes up to 100 internal testers from your own team and up to 10,000 external testers. An external group needs your first build approved by App Review for TestFlight, and builds go for that review automatically once they are added to a group. iOS distribution also needs your own Apple Developer Program membership, which is 99 USD a year, with prices varying by region.
On Android, internal testing puts a build in front of a short tester list quickly. Production is where the waiting is. A Google Play developer account costs a one time 25 USD registration fee. New personal developer accounts then have to run a closed test first. Google asks for a minimum of 12 testers who have been opted in continuously for at least 14 days, before you can apply for production access. Testers who opt in, test for fewer than 14 days and then opt out do not count. Organisation accounts are not covered by that requirement.
So start the closed test in the week the build first works, not in the week you feel finished. A tool can do the upload for you. Newly sends the iOS build to App Store Connect and pushes an Android build to Google Play internal testing. It does not press submit on your behalf, and nothing shortens that fortnight.
Google Play Console Help, testing requirements for new personal developer accounts
What each way of testing a first version actually tells you
| Way to test the idea | Real app on a phone | Usable with no signal | Changes without a new build | What it tells you |
|---|---|---|---|---|
| Landing page and a waitlist | No | No | Yes | whether the promise lands |
| Clickable prototype | No | No | Yes | whether the flow reads |
| Shared spreadsheet or form | No | with an offline copy | Yes | whether the data shape holds |
| Internal no-code tool | usually in a browser shell | cached screens only | Yes | whether the workflow survives a week |
| A built MVP on TestFlight or internal testing | Yes | only if you built for it | No | whether people open it twice |
Building an app MVP when there is no team
Most MVP advice assumes somebody who can build it. If that person is you, and you also have the customers, the constraint is hours rather than ambition. AI app builders moved that constraint: the distance from a written description to something installed on a phone is now days. That makes the scoping discipline above more important, not less, because you can now build the wrong four features very quickly.
Here is what a Newly build gives you on day one, so a scope can be honest about it. You describe the app in plain English and it writes a real React Native and Expo project you own. It runs on a cloud iPhone or Android simulator while it builds. The iOS build goes up to App Store Connect for TestFlight. From the Deploy tab, one press builds, signs and uploads an Android build to Google Play internal testing, and it also produces a standalone release APK with the JavaScript bundled in. It is $25 a month and there is no free plan. What it does not give you: built-in payments, a GitHub repository that stays in sync, or a two way code path. You pull the code with npm i -g @newly/cli and then newly pull with your project id. That direction is the only one, so changes go back through the agent rather than through your editor. iOS needs your own Apple Developer account, and the App Store submission is still a button you press yourself.
None of this replaces the cheaper step that comes before it. A build in somebody's hands answers whether they open it twice. It does not tell you whether anyone wanted it, and testing the idea first usually costs a week and saves a quarter.
Questions people ask about app MVPs
It is the smallest version of the app that completes one real job from start to finish, put in front of real users to answer a question. The point is the answer, not the feature count. One finished path teaches you more than four half finished ones, because only a finished path produces behaviour you can observe.
Write down the one job, then build only that
List the single task somebody has to finish, the records it creates, and nothing else. That list is your first version, and it is short enough to put on a phone this month.
Start building