The 3 Screens Founders Forget to Scope in an MVP App (and How to Add Them on the First Call)

Why these three screens fall off the list

Founders scope an MVP by thinking about the user: sign up, do the main thing, come back tomorrow. That's the right way to cut a v1. These three screens don't belong to that story. A new user never sees the test login. Nobody deletes their account in week one. The deletion web page doesn't even live inside the app. So they don't show up in a mockup or a pitch deck, and they get missed. The store reviewers do check for them. And if one turns up on submission day, it gets built in a hurry. Here is who asks for each screen, where the rule lives and what it is:

• Test login for review. Who asks for it: Apple and Google. Where the rule lives: Apple guideline 2.1, Play Console "App access". What it is: a working account plus written sign in steps.
• In-app account deletion. Who asks for it: Apple and Google. Where the rule lives: Apple guideline 5.1.1(v), Play account deletion policy. What it is: a button in the app that removes the account and its data.
• Data deletion web page. Who asks for it: Google. Where the rule lives: Play account deletion policy. What it is: a public URL where users ask for deletion without the app.

1. The test login for the reviewer: what the rule says

Apple's App Review Guidelines, section 2.1, ask you to "include demo account info (and turn on your back-end service!) if your app includes a login." Google's Play Console Help, in the "App access" section, says: "If your entire app or parts of your app are restricted based on login credentials, sign in details, memberships, location, or other forms of authentication, you must provide all required details to enable access to your app." Google also gives you an "Any other instructions" field for things like a "one-time password, multi-factor authentication, or logins with more than two fields."

Why the test login is a scoping item, not an admin task

A test login looks like something you type into a form at the end. Often it needs real work:

• If sign in is by SMS or email code, the reviewer can't receive that code. Someone has to build a way past that step for the review account.
• If the app is empty without content, the test account needs sample data loaded, or the reviewer sees blank screens.
• If the app is invite only, or only works in one city, the review account needs a way around that limit.

The test login line for your feature list

Access is one of the easiest rejections to prevent. Apple and Google both ask for the same thing: a way in that works on the day they test. Add this line to your scope:

• Review access: a dedicated test account with sample data, a bypass for one-time codes on that account only, written sign in steps for Apple and Google, backend kept live during review.

2. Account deletion inside the app: what the rule says

Apple's guideline 5.1.1(v): "If your app supports account creation, you must also offer account deletion within the app." Google Play's account deletion requirements ask developers to "provide users with an in-app path to delete their app accounts and associated data," and add that "the pathway should be prominent (for example, within the account settings or a similar section)."

What "delete" means for your build

A button that signs the user out doesn't count. On the server, the account and its data have to go. That raises questions to settle while you scope, not after. Each answer changes the build a little. That's why it belongs on the first call.

• What data is tied to the account: profile, photos, messages, orders?
• Is anything stored by a third party service, such as payments or analytics?
• Does the user confirm before deletion, and what do they see afterwards?

The account deletion line for your feature list

Add this line to your scope. Got an idea and not sure what your v1 needs to get approved? Book a call and we'll go through the store rules with your scope in front of us.

• Account deletion: a "Delete account" option in settings, a confirmation step, and server side removal of the account and its linked data.

3. The data deletion web page: what the rule says

This is the one founders almost never know about. Google Play's account deletion requirements also ask you to "provide a web link resource where users can request app account deletion and associated data deletion." Google sets standards for that page. The link "must be functional (for example, loads without error), relevant in scope (for example, the pathway to request account deletion should be prominently featured and easily discoverable on the page) and reference the app or developer name." Google also explains why the page exists: some users have already uninstalled the app. So the page "should give users a way to request that their data be deleted without sending the user back to the app and requiring them to re-download it."

Why the data deletion page gets missed

The page isn't in the app, so it's not in the app mockups. It's not marketing, so it's not on the website plan. It falls between the two, and nobody owns it.

The data deletion page line for your feature list

Add this line to your scope:

• Data deletion page: a public web page that names the app, explains how to request deletion of the account and its data, and accepts that request without the app installed. URL ready before the Play listing is filled in.

What about the privacy policy?

You'll need one, and both stores check it. We cover it in its own guide on the BuildMVPFast blog: what to publish before launch and what Apple and Google look at. For scoping, just remember that the deletion page and the privacy policy should describe the same process.

How to add all three on the first call

You don't need to know the store rules by heart. Bring four answers to your first call, and the three screens fall out of them:

• 1. How do users sign in? Email and password, a one-time code, Apple or Google sign in. This decides how much work the test login needs.
• 2. Is any part of the app locked? By invite, payment, role or location. Each lock needs a way through for the reviewer.
• 3. What data does an account hold? List it plainly. This sets the size of the deletion work.
• 4. Where will the app's web pages live? Your own domain is the usual answer. The deletion page goes there.

Check the written scope

Then check that the written scope has the three lines above, with the same detail as your main features. If a quote doesn't mention them, ask where they are. To see how features like these affect a build, try our app feature cost estimator. For the wider submission process, our Google Play guides and App Store guides go deeper.

How we handle it

We put the test login, account deletion and the data deletion page into the feature list on the first call, next to the features your users will see. Our mobile builds include TestFlight + Play submission support, as listed on our services page. Want a scope that already has the screens the stores ask for? Book a call. It's a free 30 minutes. Here is what you get:

• Your app on the web, iOS and Android in about 20 days.
• Progress shown every week.
• Fixed at $3,460. The quote is given before we start.
• Design included.
• Code 100% yours, on your GitHub.
• 2 weeks of fixes after launch.

Which screens do founders most often forget in an MVP scope?

Three come up repeatedly: a test login for the store reviewer, in-app account deletion, and a public web page for data deletion requests. Apple's guidelines 2.1 and 5.1.1(v) and Google Play's App access and account deletion rules cover them.

Is a "contact us to delete your account" email enough?

Not inside the app. Apple requires account deletion "within the app," and Google asks for an in-app path plus a web link where users can request deletion without reinstalling.

Does the data deletion page need to be on my own website?

Google doesn't say which domain. It says the link must load without error, make the deletion request easy to find, and name the app or developer. Your own domain is the simplest choice.

My app uses a one-time code to sign in. How does the reviewer get in?

Give them a review account with a way past the code, and explain it in your notes. Google's "Any other instructions" field is there for one-time passwords and multi-factor logins.