A good app brief fits on one page. It says what problem you're solving, for whom, the three things people will do most often in the app, on which devices, which systems it connects to, and what success looks like. It doesn't need a list of screens or a tech stack. What comes out of it is a quote with scope, phases and a timeline, not a number pulled out of thin air.
Why the brief matters
Without a brief, the conversation starts at "I want an app like X." That describes how something looks, not what problem it solves. The UK government's Service Manual makes the same point: a good user need describes the person's problem, not a solution. Their example: someone needs a reminder, not an email or a letter.
A clear brief saves both of us a month of guesswork. Our services page says the same: the quote comes after the brief, because scope decides how many screens the app has, what it does and which systems it touches.
The ten questions of a brief
- The problem, in two sentences. What's going wrong today and what it costs you (time, money, lost customers).
- Who uses it. Roles, not just "customers": who orders, who approves, who works in the field, who reads the reports.
- The three core flows. What people do most often, step by step. Everything else comes later.
- Platforms. Web, iOS, Android, or all of them. And where it gets used: at a desk, on the street, in a van.
- What already exists. The spreadsheet, the WhatsApp group, the old software. Does that data need to move over?
- Integrations. Payments, maps, invoicing, shipping, email.
- Personal data. What you collect, why, and how long you keep it.
- Deadline. And why it's that date: a season, an event, a contract.
- What success looks like. One number you can measure after launch.
- What is NOT in the first version. This list saves more projects than anything else on it.
Roles and the three flows
For each role, write the need in the format the UK Service Manual uses: "As a [role], I need to [what], so that [why]." For example: "As a technician, I need to close out a job from my phone, with photos, so that I don't have to stop by the office every evening."
Why only three flows? Because that's where it's decided whether people use the app at all. Apple's guidance for iPhone notes that people often spend just a minute or two in an app, and asks designers to help people focus on the primary task with as few onscreen controls as possible. If the first three flows are fast, the rest can come in later versions.
An example: a towing app usually has three roles linked in real time, the customer, partner companies and drivers. Each role has its own flow, and in the brief each one gets its own three flows, written separately.
Platforms, and what the app stores expect
Not every idea needs an App Store listing. A web app runs on any phone, needs no install and updates for everyone at once. A store app makes sense when it leans heavily on the phone's features (camera, notifications, working without signal) or when you want people to find you in the store.
If you go the store route, a few of Apple's rules belong in the brief from day one:
- the app needs a link to its privacy policy, both in the store listing and inside the app;
- if people can create an account, they must be able to delete it from within the app;
- an app that's just a repackaged website can be rejected.
Data and GDPR
The brief should say what personal data the app collects and why. The EU General Data Protection Regulation requires data to be limited to what's necessary for the purpose (data minimization) and requires data protection to be built in from the design stage, with defaults that only process what's needed.
In practice: if you only need location at clock-in, the app asks for it at clock-in, not all day. If we build and host the app, we process your data on your behalf, and the regulation requires a written contract for that. It helps to know from the brief who sits on which side.
A filled-in example
The company is made up: a heating installation firm with 12 people in the field.
| Question | Answer |
|---|---|
| Problem | Jobs are handed out on WhatsApp, photos get lost, timesheets are pieced together from messages at month end. Closing the month takes three days. |
| Roles | owner, office (dispatcher), technician |
| Flows | 1. The office assigns a job to a technician. 2. The technician closes it from their phone, with photos and the customer's signature. 3. The owner sees the monthly timesheet and exports it. |
| Platforms | web app on phones for technicians, on desktop for the office |
| What exists | a spreadsheet of customers and addresses, to import |
| Integrations | maps (job address), export to the invoicing software |
| Data | name, phone, customer address; technician location only at the start and end of each job |
| Deadline | before boiler service season |
| Success | the month closes in one day instead of three |
| Not now | online payments, store app, customer portal |
That's half a page. From it we can estimate scope, phases and timeline, and say what can be built first. For companies that track timesheets or jobs in spreadsheets and WhatsApp, we usually start with a single module and build the rest on the same system.
Sources
- Learning about users and their needs, GOV.UK Service Manualthe "As a… I need… so that…" format and the point that a need describes the problem, not the solution
- Designing for iOS, Apple Human Interface Guidelinesshort sessions of a minute or two and the advice to keep the primary task front and center with few onscreen controls
- App Review Guidelines, Apple5.1.1 (privacy policy link, in-app account deletion) and 4.2 (apps that are just a repackaged website)
- Regulation (EU) 2016/679 (GDPR), EUR-LexArt. 5(1)(c) data minimization, Art. 25 data protection by design and by default, Art. 28(3) processor contract
Checked: surse Xenia Pușcașu · editare Nora Vlăsceanu · SEO Mihnea Tăbăcaru