Mobile app requirements: what to write before you ask for a price

You have an idea, a deadline and a short list of studios to ask what the app would cost. Every one of them asks for the same thing before naming a number: the requirements. For a buyer, mobile app requirements are not an engineer’s specification, and they are not the list of phones an existing app runs on. They are one page that a studio can read, picture and price.

This is the founder’s version. It is built around one journey and adds the layer a general brief misses: the phones your users carry, the parts that live outside your app, and the accounts that must be in your name. At the end there is a one-page template to copy. It is the page we ask for before we price mobile app development, and it works as well for any other studio on your list.

What a requirements page is for

The page has two jobs. The first is the estimate: a studio reads it and works out what the build involves. The second is the first release: once work starts, everybody checks the same page when a feature is in question.

A vague list does not get a low price. Every line a studio cannot picture is a risk, and risk gets priced in on the cautious side. A line that says “users can pay” could mean one card payment or money held between a buyer and a seller, and the estimate has to allow for the harder reading.

Good mobile app requirements remove those guesses. The general version of this page, a software requirements document for any kind of project, has its own article. What follows is the layer only a phone brings.

Start the page with one journey

The first release we build is one journey that matters, working end to end on iOS and Android. Pick the one thing a person opens the app to do: an order placed, a job accepted, a piece of work delivered — the thing people install it for. Write it down step by step, from opening the app to the job done, in your users’ words.

Everything else waits, deliberately. If you already run a website, say which part of it the app is meant to carry.

Two lines on the page decide whether this should be an app at all:

• How often. If people would use it less than once a week, the browser is usually enough.
• What the phone brings. The product needs something a phone has: a camera, a location, a notification that arrives. Name it.

Then say whether anyone has tried the idea yet. If nobody outside your team has seen it, write that down: the store is an expensive place to learn.

The parts that live outside your app

A mobile app meets permissions, payment sheets, notifications, background kills and a network that drops. None of that shows up on a developer’s desk. It is not your code either, and all of it can break your product, so each part gets a line on your page.

Permissions. A permission is the dialog in which the phone asks your user whether the app may use the camera or the location, or send notifications. Write down which ones the journey needs and what should happen when the user says no.

The payment sheet. This is the payment screen that slides up over your app, drawn by the phone or the payment provider, not by your code. It lives outside your app, which is exactly why it needs a test that leaves it. Write down whether money moves at all, who pays whom, and for what.

Notifications. A push notification is a message that reaches the phone even when the app is closed. List the events that should send one, and to whom, including those that must arrive on a locked phone.

The app closed in the background. Android kills backgrounded apps eagerly: the phone quietly closes an app nobody is looking at. Coming back to a working screen is a feature, so write down what a user should see on reopening the app three days later, halfway through the journey.

A network that drops. Say what the journey should do on a weak signal: wait, try again, or keep the user’s work and send it once the connection returns.

Which phones. The device question belongs here, as one line rather than a chapter: who uses the app, and on which phones. In our projects your team tests the app on their own phones, old Androids included, because that is what your customers have.

Accounts, stores and the server

Sign-in and its awkward states. Write down how people get in and what happens around it: expired sessions, lockouts, password reset. Name the kinds of user too, such as customer, staff and administrator, and what each one may do.

Store accounts and signing keys. To publish an app you need a developer account with Apple and another with Google, plus signing keys: the digital credentials that mark each new version as coming from you. Say on the page that the accounts and the keys will be in your name. We do not publish under our own developer account: it is your product, so the account and the keys are yours from the start, and you are never locked out of it.

The server. Almost every app worth building is a client for something: accounts, money, moderation, disputes, the admin screen where a human sorts out what the app could not. The server, often called the backend, runs away from the phone and keeps all of that. Write down whether one exists, or “nothing yet”, and whether it has an API: a way in through which an app asks the server for data.

Admin work. List what a person on your side does by hand: moderation, disputes, refunds. That side runs in the browser, because nobody wants to settle a dispute on a phone.

One platform or both. Say whether you need iOS, Android or both at launch. We build cross-platform by default, one set of code for both platforms, and say plainly when native, built separately for each platform, is the better answer. Built cross-platform, both apps cost almost the same as one; if your users are overwhelmingly on one of them, check your website analytics before deciding.

What goes into a mobile app requirements document, and what stays out

Everything in the three sections above goes in: the journey, the parts outside your app, and the accounts, stores and server. What stays out is anything that makes the page longer without making the estimate better, and anything the first release should not carry:

• A design system. A full library of reusable screen parts and rules is premature for a product that has not met users yet.
• Store marketing. Ongoing store optimisation, screenshots and ad campaigns are work for after launch.
• Promised review dates. Apple and Google review each app before it goes live, and they decide how long that takes. We do not promise store review times: nobody can, and the ones who do are guessing with your launch date.
• Everything the web version does. The first release is one journey, not a copy of the website.

One refusal belongs here too: games, AR (augmented reality, graphics laid over the camera view) and anything that lives or dies on frame rate, the smoothness of motion on screen, are not our trade. If that is your product, look for a studio that specialises in it.

Phase two does belong on the page, written down as waiting. A list marked “phase two” keeps those ideas out of the first release. It stays a list, not a plan: the first release exists to be argued with by real people, and phase two is quoted from what they actually did, not from what the plan assumed they would.

One more line goes in: who keeps the app alive after launch. Stores expire builds and platforms change every year, so somebody has to update it: your own team, or the studio that built it. We sell support after launch: the first six months of defect fixes are in the price, then a monthly arrangement quoted against what the app needs. Write down which you want before anything is built, because an unmaintained app is worse than none.

A one-page mobile app requirements template

Copy these lines into a document and answer each in a sentence or two. It is a page to copy, not a file to download.

• The product in one sentence: who it is for and what it lets them do.
• The one journey, step by step: from opening the app to the job done.
• Who uses it, how often, on which phones: customers, staff or both; daily or weekly; iPhones, Androids, old models included.
• What the phone must do: camera, location, notifications, or none of these.
• Does money move, and between whom: nobody, customer to you, or customer to another user through you.
• The parts outside the app: which permissions, whether there is a payment sheet, which notifications, what happens after a background kill or a dropped connection.
• Accounts and roles: how people sign in, what happens after an expired session, a lockout or a password reset, and who may do what.
• The server: what exists and whether it has a way in for an app, or nothing yet.
• Admin work that belongs in a browser: moderation, disputes, refunds, reports.
• Whose store accounts: yours, with the signing keys in your name.
• What waits for phase two: everything you want that the first journey does not need.
• Who on your side answers questions: one person who knows the business and can test on their own phone.

If a line has no answer yet, write “not decided” rather than leaving it out. A gap that is named gets a question; a gap that is missing gets priced as risk.

What happens to the page once you send it

Send the page to us and a basic estimate comes back within 12 hours, with the scope it covers and the list of things we assumed. If the page shows that a mobile-friendly website would do the same job, we will say so.

A requirements page does not lock the price. The estimate is “from”, and a change in scope is quoted before the work on it starts. If you want the scope pinned down before you commit, there is an optional stage priced on its own: a written specification and clickable screens, yours to take to any vendor, with its fee coming off the project if you go on.

If you go ahead, week one is sessions with the people who will use the app and a walk through what exists. It ends with an agreed scope, the platform decision with its reasoning, and store accounts opened in your name. From the second week there is a build on your phone, an installable version that gets better every few days, which is also how you find out early whether you want to keep going.

A first release with one journey working on both platforms starts from $19,000 for eight weeks. It is paid by stage, and no stage grows unless the scope changes. You can stop after any stage, and what is built stays with you. The full scope of that first release is on the mobile app development page.

For large systems one page grows into a document of its own. On our browser-based operations platform, which is not an app, every user action was written as screen, action, system response and result, and reviewed with the client before anything was designed. That document is where the arguments happen while they are still cheap. Most of what we build is client work under NDA, a non-disclosure agreement, so there are no client stories here; the only app we can show whole is our own marketplace.

The next step: send the page

Write the page, even if some lines still say “not decided”, and send it to every studio on your list. The same page makes their answers comparable. If you send it to us, a basic estimate comes back within 12 hours, and what you do with it is up to you.