An app brief is the document a developer reads before they quote. This guide shows what goes in it, how to describe users and features, and which details people leave out.
An app brief is a short document that tells a developer what your app is for, who will use it, what they must be able to do, which phones and systems it must work with, and what you will supply. Two to four pages is enough for a first version. Describe the problem, rank the features and let the developer recommend the technology.
What an app brief is and what it is for
An app brief is a written description of the app you want built, given to a developer before they quote. It says what problem the app solves, who will use it, what those people must be able to do and what you will supply. Developers use it to estimate the work and to decide which questions to ask. Without one, each team fills the gaps with its own assumptions, and the quotes you collect describe different apps.
An app brief is not a technical specification. You are not expected to choose a framework, a database or a server. Your part is the business problem and the facts only you know. The developer's part is to propose how to build it and to say what they have assumed.
If you have written a website brief for a developer, the idea is the same. An app raises questions that a website does not: which phones it must run on, whether people log in, what data it stores, what it connects to and how it reaches the Apple and Google stores. The stages that follow the brief, from design to store launch, are set out in the mobile app development process.
What to include in an app brief
Work through the headings below in order and answer in plain sentences. Where you do not know, write "not sure", which tells the developer where to ask.
| Section | What to write |
|---|---|
| The business and the problem | What you do, who your customers are and what goes wrong today without the app. |
| Goal | The one result the app should produce, and how you will know it did. |
| Users | Each kind of person who will use it, what they want and in what situation. |
| Features by priority | A list sorted into must have, should have and later, with a line on what "working" means for each. |
| Screens and flows | A rough sketch or a list of steps for the main task. Photographs of paper sketches are fine. |
| Platforms and devices | iPhone, Android or both, tablets, and what your customers actually carry. |
| Data and accounts | What the app stores, how people sign in and which accounts already exist. |
| Connections | Other systems it must talk to, such as payments, billing, stock or your website. |
| What you will supply | Text, images, logo files, product data and test accounts, each with a date. |
| Running the app | Who manages content, who answers customers and who pays for hosting and store fees. |
| Timeline, budget, decisions | Any fixed date, your budget position and the one person who approves work. |
A short example of an app brief
The paragraph below is invented. It shows the level of detail that works.
We run a neighbourhood laundry with two shops and a delivery van. Customers now phone or message us to arrange pick-ups, and we write the orders in a notebook. We want an app where a customer chooses a pick-up slot, lists what they are sending and sees when it is ready. Staff need a screen that shows the day's pick-ups and lets them mark each order as collected, being washed or ready. Most of our customers use Android phones. Must have: sign-in with a phone number, slot booking, order status and the staff screen. Should have: a reminder before the slot. Later: online payment and loyalty points. We will supply the logo, the price list and all text by a date we agree. The shop manager approves designs and answers questions the same week.
How to describe the users in an app brief
Describe each kind of user in a few lines, because their situation shapes the design more than their age or job title does. Cover who they are, what they want to do, where they will be when they do it, which phone and connection they have, which languages they read and how confident they are with apps. Two short entries are better than a paragraph about "everyone".
- A customer booking from home in the evening on a mid-range Android phone, reading English as a second language.
- A counter assistant at a busy shop, using the staff screen on a shared device, one-handed, between customers.
Include the people who never open the customer app. The staff member who runs the admin screen and the owner who wants a weekly report are users too, and they are the group most often left out. Say roughly how many people you expect in the first year, and what a busy day looks like. A guess is fine if you mark it as a guess. If you have website analytics or customer messages, quote what they show in words. If you have neither, write what customers tell you.
How to write the feature list
Write each feature as one sentence about what a user can do, then say what "working" means. The second part is what most briefs lack. It lets the developer show that a feature works and lets you say whether it is finished. The table continues the laundry example.
| Feature | Priority | What working means |
|---|---|---|
| A customer books a pick-up slot | Must have | The customer picks a date and a slot, sees a confirmation, and a full slot can no longer be chosen. |
| A customer sees the order status | Must have | When staff change the status, the customer sees the new one on opening the app. |
| Staff see the day's pick-ups | Must have | A list in time order with each customer's name, address and phone number. |
| A reminder before the slot | Should have | A notification arrives before the slot. If the customer has switched notifications off, booking still works. |
| Online payment | Later | Not in the first version. Customers pay on delivery. |
Deciding which features belong in the first release is a separate job. The guide to what to build in the first version of your app covers it, so bring that list here instead of redoing it.
Platforms, devices and the technology question
Say which phones your customers use and which platforms you need at launch. If you do not know, ask a sample of customers, and check whatever device reports your website analytics offer. An app for a mostly Android audience and an app for a mostly iPhone audience can reasonably be planned differently.
You do not have to choose between native and cross-platform in the brief. Name the platforms, say which can wait, and ask the developer to recommend an approach and explain it. The trade-offs are laid out in Flutter vs React Native vs native.
Ask how old a phone the app will support. Older phones need extra testing, and dropping them removes some customers. Settle it from your customer mix, not from the developer's preference. Also say whether staff will use a desktop admin website, and whether tablets matter.
Data, accounts and connections to other systems
List what the app will store: names, phone numbers, addresses, photographs, location, payment details. This matters beyond the build. The Apple App Store and Google Play both ask developers to declare what an app collects, including what is collected by third-party code inside it, and both ask for a link to a privacy policy. The forms change, so check the current store documentation. Payments, health information and data about children bring extra rules in many countries, so ask a lawyer before you promise them.
Say how people will sign in, what happens when they forget how, and whether they can delete their account. Both stores have rules for apps that create accounts, so check their current policies.
Name every system the app must connect to, such as billing software, stock records, a customer list or your website. If you do not know whether it can be connected, give the software name and who manages it. The developer can find out. Add any outside services you expect, such as maps, text messages, email sending or a payment gateway. Each usually needs its own account, and each can carry running costs. Say who will open it and whose name it will be in.
What developers need that people forget
These items rarely appear in a first draft and often change the quote.
- The admin side. Say who will manage content, orders and users, what they need to see and whether different staff need different access.
- Behaviour without a signal. Say whether the app must work offline, and what the user should see when it cannot reach the server.
- Notifications. Say what triggers them, who writes the wording and what should happen when users switch them off, which they can do on both platforms.
- Languages and scripts. If the app must work in another language as well as English, say so at the start. Longer text and different scripts affect how screens are laid out.
- Content. Say who writes the text and supplies images and product data, in what format and by when. Screens cannot be finished without them.
- Accessibility. Say what you expect. Apple and Google each publish accessibility guidance for app developers, both phones have a built-in screen reader (VoiceOver and TalkBack), and W3C publishes guidance on applying its web guidelines to mobile apps. Ask which guidance the team tests against.
- Testing and sign-off. Say who tests, on which phones, and who decides that a feature is accepted.
- Measurement. Say which numbers you want after launch, so analytics and crash reports are built in from the start.
- Brand files. The app icon needs a square version of your logo, and the screens need your colours, fonts and image rules.
- After launch. Say who updates the app when new phone software is released, who pays store and hosting fees, and that the store accounts and source code should be in your name.
Should you put a budget in an app brief?
Usually yes, as a ceiling or a range. App costs vary widely with scope, and a developer who does not know your limit has to guess. Say what the figure must cover. An app involves more than screens: the back end, the admin area, testing on real phones, store submission and the first year of running costs may or may not be inside it. If you leave that unsaid, two developers can quote for different things.
If the project can run in phases, say so, and ask for the first version to be priced apart from later phases. If you cannot give a figure yet, rank the features and ask each developer what moves the price. Compare quotes by what each one includes as well as by the total.
How long an app brief should be
For a first version with one main task, two to four pages is enough. An app with several user types, payments or an admin system needs more. Put bulky material in attachments: sketches of the main screens, the fields of any forms, a sample of data to import, screenshots of apps with behaviour you like (say which behaviour), and your logo and colour files. Delete anything that would not change the price or the plan.
Before you send the app brief
Ask someone outside the business to read it and tell you what the app does. If they cannot, rewrite the goal and users. Check that each must-have feature appears in your screens or steps. Send the same brief to every developer you speak to, and ask each to reply with questions before they quote. The best replies restate your goal, list what they have assumed and say what they would leave for later. A generic proposal that ignores your details suggests the brief was not read. The mobile app development page describes the app work Liftup does.
Questions and answers
What is an app brief?
An app brief is a short document you give a developer before they quote. It explains what the app is for, who will use it, what they must be able to do and what you will supply. It is not a technical specification, and you do not need to choose the technology.
What should an app brief include?
Include the business problem, the goal, the users, a prioritised feature list, the platforms and devices, the data and accounts involved, connections to other systems, what you will supply, who runs the app after launch, and your timeline, budget and decision-maker. Mark any answer you are unsure of.
How long should an app brief be?
Two to four pages usually covers a first version with one main task. Apps with several user types, payments or an admin system need more. Move bulky material, such as sketches, sample data and brand files, into attachments so the brief itself stays short.
Should I name a budget in an app brief?
Usually yes, as a ceiling or a range, together with what it must cover: build, back end, admin area, testing, store submission and early running costs. If the project can be phased, ask for the first version to be priced separately from later ones.
How do I describe the users of my app?
Write two or three short entries covering who each user is, what they want to do, where they will be, which phone and connection they have and which languages they read. Include the staff who use the admin side as well as customers.
What do developers need that people forget?
The admin side, behaviour with no signal, notification rules, languages, who supplies content and when, accessibility expectations, who tests and approves, the numbers to measure after launch, and who maintains the app and holds the store accounts. These often change the quote.
Do I need designs or wireframes before writing a brief?
No. Rough sketches of the main steps help, and photographs of paper drawings are fine. Proper screen designs and a clickable prototype are produced later in the project, once the developer has read your brief and agreed the scope.