Mobile App Requirements Document: The 9 Decisions to Write Down Before You Ask for a Quote
Short answer: a useful mobile app requirements document fits on two pages and answers nine questions. Three of them are not really yours to decide: they come from Apple's and Google Play's rules, and no downloadable template can settle them for you.
A supplier does not price an idea, it prices decisions. Every point left open gets filled with an assumption, a different one in each quote, and you end up comparing prices that do not describe the same project. Compared with a website, an app adds one party the web does not have: the store, which reviews your app before letting it appear.
The nine decisions to write down
1. The main action. The one thing the user comes to do, in a single sentence with a verb: book a slot, scan a parcel, follow a session. If you need three sentences, there are probably three apps inside your project.
2. The devices. iPhone, Android, both, with or without tablets. Say what you know about your users' hardware too: a fleet of company-issued phones does not call for the same answer as a consumer audience.
3. Account or no account. This line has a regulatory consequence. The App Store guidelines ask you to let people use the app without a login when it has no significant account-based features, and state that if the app supports account creation it must also offer account deletion within the app. Google Play additionally asks for a web link where deletion can be requested. Account deletion is therefore a feature to be priced, not an end-of-project detail.
4. The data collected. List it: email, location, photos, health data, advertising identifiers. Apple requires a link to a privacy policy in the app's store metadata and inside the app; Google Play has you complete a Data safety form. Those declarations are public and bind the publisher, which is you.
5. Offline. Does the app have to work without a network, and if so for which actions exactly? "Read" and "enter now, sync later" are not the same amount of work.
6. The money. What does the app sell, and to whom? The distinction that matters is the one in the App Store guidelines: physical goods and services consumed outside the app are paid for with methods other than in-app purchase (card entry, Apple Pay), while digital content and services fall under in-app purchase. Apple's developer program page states a 30% commission on those digital sales, or 15% under certain programs including the App Store Small Business Program. Terms vary by region: have this checked for your market before you set a selling price.
7. Notifications. Which ones, triggered by what, and who writes them. A notification implies a server-side event: each type requested is a feature in its own right.
8. Administration. Who manages content, users and orders, and with what tool. The admin interface is the invisible half of the project: check that it appears in every quote you receive.
9. The developer accounts. Who holds them, you or the supplier, and who pays the fees. This decides who actually owns the app the day the collaboration ends.
What the stores impose, and your document has to plan for
The rules below were read on Apple's and Google's official pages on 7 October 2026. They change: the reading date matters as much as the figure.
| Rule | App Store (Apple) | Google Play |
|---|---|---|
| Account fee | 99 USD per membership year | 25 USD, one time |
| Account deletion | Required in the app if it supports account creation | In the app, plus a web link |
| Privacy | Privacy policy link in the store metadata and in the app | Data safety form |
| Before production | App review against the App Store guidelines | Personal accounts created after 13 November 2023: closed test with at least 12 testers opted in for 14 consecutive days |
That last row moves a schedule. If the Google Play account is a recent personal account, twelve testers have to be gathered and kept opted in for two weeks before production access can be requested. A requirements document that announces a launch date without saying who opens the account, and under which status, announces a date it does not control. Google Play also sets a minimum Android target API level each year: the matching update belongs to yearly upkeep, a recurring line of the same kind as the ones in our guide to maintenance costs, and deserves a sentence in the document.
What is better left out
The technology. Native, cross-platform or an installable web app: that is an answer, not a requirement. Describe the constraints and let each supplier justify its choice.
A number of screens. Ten read-only screens and ten data-entry screens that sync offline do not cost the same.
"Like that well-known app". The reference describes a visible result, not the years of work and the infrastructure behind it. Name the precise screen or journey you are interested in instead.
A two-page template you can copy
- Context (five lines): who you are, who the app is for, what it replaces today.
- The nine decisions, one to three lines each.
- First release and later: two separate lists, what must exist at launch and what can wait.
- What already exists: logo, brand guidelines, copy, data to migrate, accounts already open, tools to connect.
- Constraints: target date, budget envelope, the person who decides.
- What you expect back: an itemised quote, the assumptions made, the recurring cost after delivery.
Once this document exists, the ranges in our guide to custom mobile app development cost become readable: you know which bracket your project falls into, and why.
Frequently asked questions
What should a mobile app requirements document include?
Nine decisions are enough: the user's main action, the target devices, whether there is an account, the data collected, offline behaviour, how money moves, notifications, the admin tool and who holds the developer accounts. Add a list of what already exists (logo, copy, data, accounts) and a date. Two pages will do, provided every line is a decision and not an intention.
Do I need a Word or PDF template for my app requirements?
The format does not matter. A template gives you headings, not answers. A two-page document that settles the nine points above produces quotes you can compare; a thirty-page template filled with vague wording produces quotes that describe different projects.
How much does a developer account cost to publish an app?
According to the official pages read on 7 October 2026: the Apple Developer Program is 99 USD per membership year, and Google Play charges a one-time registration fee of 25 USD. These are the store operators' own figures, they may be shown in local currency, and they cover neither development nor maintenance of the app.
Who should own the developer account, the client or the agency?
The client, unless there is a specific reason otherwise. The app, its reviews and its users are attached to the account that publishes it. Writing in the requirements document that the Apple and Google accounts are opened in the client company's name avoids having to arrange a transfer the day the relationship with the supplier ends.
Should the requirements document specify the technology?
No. Describe the need and the constraints (devices, offline use, access to phone hardware), then ask each supplier to justify its proposal: native, cross-platform or an installable web app. The justification tells you more about the supplier than the choice itself.
Only have three of the nine answers?
That is enough to start. Send us what you have, even a few lines: we reply with the questions that are missing, then an itemised quote that includes store fees and maintenance. No commitment.
Send my app projectSources
- Apple, Apple Developer Program, "What's included": membership fee and commission (read 7 October 2026).
- Apple, App Store Review Guidelines, sections 3.1.3(e) and 5.1.1: payments outside the app, privacy policy, account deletion (read 7 October 2026).
- Google, Play Console Help: registration fee, testing requirements for new personal accounts, account deletion, target API level (read 7 October 2026).