Checklist: writing an app brief
For: Clients commissioning an app
Updated: 2026-11
A good app brief describes the goal and user groups, the three to five most important flows, platform requirements, the necessary data and interfaces, requirements for operations and data protection, and measurable success criteria. It leaves the technical solution open and makes proposals comparable.
Many app requests consist of an idea and a list of desired features. Proposals based on them are hardly comparable because every supplier assumes something different.
This checklist leads to a brief suppliers can understand and answer comparably. It does not replace a requirements analysis but is its best foundation.
The checklist
- 01
State the goal
Describe in two sentences which problem the app solves for whom and why now.
Done when: An outsider can restate the goal in their own words after reading.
- 02
Describe user groups
Who uses the app, in what situation, on which device and with what prior knowledge.
Done when: Each user group is described with a typical usage situation.
- 03
Define core flows
Describe the three to five most important flows step by step from the user’s perspective.
Done when: Flows are prioritised and it is clear what a first version must include.
- 04
Clarify platform requirements
Record whether the app must run in the browser, on the home screen or from the app store and which device features are needed.
Done when: Required device features are named, such as camera, location or offline use.
- 05
Name data and interfaces
Which data arises, where it comes from and which systems the app must talk to.
Done when: Every interface is listed with system, direction and contact person.
- 06
Record operations and data protection
Describe requirements for hosting, data location, availability, support and data protection.
Done when: The desired data location and support expectations are set out in writing.
- 07
Define success criteria
How to measure after six months whether the app achieves its goal.
Done when: At least two measurable criteria are set, with how they will be collected.
Common mistakes
- —Supplying a long feature list instead of prioritised flows.
- —Prescribing technology before requirements are clear.
- —Forgetting interfaces and existing systems, which often cause most effort.
- —Not mentioning operations after launch.
What this checklist does not cover
- —A brief does not replace a requirements analysis with acceptance criteria; fixed-price proposals usually need one.
- —Legal requirements on the app’s content and data processing must be reviewed separately.
- —The checklist covers design and branding only marginally.
Parent service: App Development
Matching offers
PWA development: an installable web app instead of a store app
We build Progressive Web Apps on Next.js and Supabase: one codebase for phone and desktop, installable to the home screen, with defined offline behaviour, web push and data held in Zurich or Frankfurt. Scope is set during scoping, after which a fixed price applies.
Fixed-price MVP development
Fixed-price MVP development delivers a clearly scoped, working product at a price defined up front — on a modern, EU-hosted stack. Not an open-ended hours bucket, but a defined scope with a clear result.
Requirements analysis (IREB)
We elicit, document and validate requirements following the IREB Certified Professional for Requirements Engineering method: identify stakeholders, elicit requirements in workshops, model processes in BPMN 2.0, write acceptance criteria and deliver a requirements catalogue the client can formally sign off. A basis for tenders, development or standard software.
FAQ
How long should a brief be?
As short as possible, as long as necessary. Two to four pages are often enough if the flows are clearly described.
Should I state a budget?
A range helps suppliers make fitting proposals rather than offering the maximum or minimum.
Must I choose between PWA and native app?
Not in the brief. Describe the required device features; the platform choice follows from them.
More checklists
Checklist: a secure Microsoft 365 baseline configuration
A secure Microsoft 365 baseline covers seven points: multi-factor sign-in for everyone, few and specially protected administrators, legacy sign-in protocols disabled, restricted consent to third-party apps, active logging, SPF, DKIM and DMARC for your domains, and an independent backup of the data.
Checklist: submitting a bid for a public tender
Before submission, check seven points: deadline, place and form, completeness of all required documents, validity of evidence of suitability, a price sheet exactly per template without reservations, legally valid signatures, correctly labelled variants and proof of receipt.
Checklist: answering access requests under the Swiss FADP and GDPR
An access request is answered in seven steps: record intake and start the deadline, check identity proportionately, clarify scope, search all systems for data, check restrictions, compile the response with the statutory content and deliver it securely and on time, with documentation.