Contents6
Requirements documents have a bad reputation, often deservedly: a long document written once, read by nobody, which describes features rather than needs. Yet it is the document that decides whether three quotes can be compared, whether the project stays on budget, and whether anyone can say, at delivery, that it is finished. What matters is not its length but what it lets you settle.
In short
A useful requirements document does three things: lets you compare quotes, fixes day one, tells you when it is finished.
It describes uses and outcomes, not a list of features or technical choices imposed without reason.
Seven elements matter: users, day one, data and rights, integrations, constraints, ownership, operations.
Obligations (personal data, account deletion, accessibility) go in from the start, when they cost the least.
A clickable prototype complements it: it shows what words describe badly.
What a requirements document is for
A requirements document is not a formality before the real work. It provides three services, which you measure throughout the project.
- Comparing quotes. Three developers reading the same document price the same thing. Without it, each prices their own idea of the project, and the price gap tells you nothing.
- Fixing day one. Overruns often come from features added along the way. A written scope lets you say “yes, in the next version” without conflict.
- Knowing when it is finished. Written acceptance criteria (“a technician records a job with three photos in under a minute”) turn delivery into a check rather than a debate.
From need to quote
- The need
The action to simplify, and for whom.
- The prototype
A few screens tested with real users.
- The requirements
What was validated, written and bounded.
- The quote
Each decision priced separately, operations included.
The seven elements that matter
1. Who uses it, and for what
The users, named by role (the technician, the client, the accountant), and for each the two or three actions they must be able to perform. A journey described in one sentence (“the client uploads a missing document from their phone and receives a confirmation”) is worth more than a list of forty features.
2. Day one, and what will wait
The short list of what the app does at launch, and the longer list of what comes later. It is the decision that weighs most on the price of an app.
From the field
Challenge Us: a one-sentence need, live the next day
The need behind Challenge Us, a group-challenge app we developed, fitted in one sentence: set a goal as a group, enter your day, see everyone else’s live, with no complicated sign-up. Scoped on 1 September 2026, its first version was running in the browser on 2 September. The details are in the Challenge Us case study.
3. The data, and who sees what
What information the app keeps, where it comes from, and for each role what it can read and change. It is the foundation of app security, and it is what makes possible a client portal where everyone sees only their own files.
4. The software to connect
The CRM, the ERP, the invoicing tool: for each, what flows in which direction, and whether it has a documented programming interface. It is often the most uncertain line in a quote; a good requirements document lets the developer say so.
5. The conditions of use
The real conditions: company or personal phones, no network on some sites (see the offline app), languages, expected notifications (see push notifications), payments (see subscriptions), AI features (see AI in an app). And the distribution channel: browser, stores or private distribution, compared in PWA or native app.
6. Ownership
The code, the database, the developer accounts, the hosting and the domain in your name, and a written assignment of rights. It is what saves you from one day having to take over an app abandoned by its developer, and what publishing under your own developer account explains.
7. Operations after launch
Who monitors, who fixes, within what time, and the monthly cost line by line: hosting, database, emails, store accounts, mandatory updates. The details are in an app’s maintenance budget.
Obligations to write in from the start
Some requirements cost little at the start and a lot to retrofit. They belong in the requirements document.
- Data protection by design. Article 25 of the GDPR requires data protection to be built in when the processing is designed, and by default only the data necessary for each purpose to be processed, according to the text published by the CNIL, the French data protection authority. Data you do not collect does not need protecting.
- Account deletion. Apple’s review guidelines are clear: an app that supports account creation must also offer account deletion within the app, according to guideline 5.1.1.
- Accessibility. Since 28 June 2025, the European Accessibility Act applies to certain services provided to consumers, including e-commerce and banking. Even when it does not apply to you, an app everyone can read also serves your users in a hurry, in bright sunlight or using one hand.
Key takeaway
Written into the requirements, these obligations are priced and tested like everything else. Discovered at release time, they delay launch.
What has no place in a requirements document
What helps the project
Journeys described in one sentence, with their user
A short day one, and the list of what will wait
Verifiable acceptance criteria
What weighs it down
A wish list without priorities
Technical choices imposed without a business reason
Pages copied from a template, which do not talk about your business
Imposing a technology is not forbidden when there is a reason: your teams already maintain that language, your IT department mandates a hosting provider. Without a reason, better to describe the expected outcome, let the developer propose, then compare proposals. If a tool without developers could be enough, the requirements will reveal that too: it is the subject of low-code or code.
Where to start
First write, on one page, the users and their actions, then day one. Have those actions tested on a clickable prototype before completing the rest: the prototype will drop useless features and reveal others. If you are still torn between building and buying, the grid in custom or off-the-shelf is filled in with the same information. For a field app, start from what it changes for your teams; for the back end, from Supabase, Firebase or your own server. And if the idea is to generate everything with AI, vibe coding says what remains for humans to decide.
Frequently asked questions
How many pages should an app requirements document be?
There is no right length. For a first version, a few pages are often enough, if they describe the users, their actions, day one, data and rights, integrations and ownership. A long document listing features without priorities helps less than a short one that makes decisions.
Who should write the requirements document?
The company commissioning the app knows the need, the users and the constraints: it owns the substance. A developer can help structure and complete it, often during a scoping phase. What matters is that the final version is approved by those who will use the app.
Do you need a requirements document for a small app?
Yes, even a one-page one. Without it, you cannot compare two quotes or know when the app is finished. For a small app, it comes down to the users, the day-one actions, the data and the ownership of code and accounts.
Can the requirements change during the project?
Yes, and that is normal: users’ first feedback shifts priorities. What matters is that each change is written, priced and accepted before it is developed, so the quote and the schedule stay readable. Day one stays short, and additions go into the next version.
Sources
- CNIL, GDPR, chapter 4 (new tab)cnil.fr
- App Store Review Guidelines, Apple (new tab)developer.apple.com
- Directive (EU) 2019/882, EUR-Lex (new tab)eur-lex.europa.eu
Jim · founder of Brain Plus AI
Also in web and mobile apps
Practical guide5 min
Clickable prototype: test an app before writing code
A clickable prototype can be explored like a real app, without the cost of one. Tested with a few future users, it shows what blocks them before development starts, and fixes what the quote must price.
Choose and price6 min
How much an app costs: what makes the price vary
A price range says nothing about your project: what makes an app quote vary is a handful of specific decisions, plus a monthly running cost to be priced separately. Here they are.
Choose and price6 min
Business app: custom-built or off-the-shelf software?
Off-the-shelf software costs less as long as your way of working fits its boxes. Here are the signs that tip the balance towards custom, and the middle path that is often forgotten.