A successful app project starts long before the first line of code. The project brief (or requirements document) aligns everyone on what the application must achieve, for whom and under which constraints. It does not need to run to a hundred pages: a good brief is clear, prioritised and focused on how people will use the app. Here are the questions to answer, in order.
Why the brief matters so much
Most projects that go off the rails do not suffer from a technical problem but from a misunderstanding: a feature the client thought obvious and never mentioned, a forgotten user, an integration discovered halfway through. A brief does not remove the unexpected, but it greatly reduces those surprises and lets you obtain comparable quotes.
Nor is the aim to freeze everything. Modern projects move forward in iterations: the brief sets the direction, the priorities and the scope of the first version; the detail is refined release by release.
1. Context and objectives
Start with the why, not with a list of features.
- What problem must the app solve? What happens today (spreadsheets, paper, re-keying, scattered tools)?
- What result do you expect, and how will you measure it? Time saved, errors avoided, new customers, better visibility of the business.
- Why now? A deadline, growth, a tool reaching end of life?
A measurable objective then helps you weigh every feature: does it contribute to the goal?
2. The users
List everyone who will use the app or receive information from it, with their context.
| Profile | Where and how | What they need to do |
|---|---|---|
| Field technician | Smartphone, sometimes offline | View their jobs, file a report, take photos |
| Admin assistant | Computer, in the office | Schedule, invoice, chase payments |
| Manager | Computer and phone | Follow activity at a glance |
| Customer | Web browser | Track their request, download documents |
This table often answers a key question: do you need a mobile app, a web application, or both?
3. Features, prioritised
Describe features as journeys: “the technician opens today’s job, checks the customer’s history, files a report with photos and has the customer sign on screen”. It says far more than a list of keywords.
Then prioritise. A simple method is to put each feature into one of three categories:
- Essential: without it, the app is pointless. This is the scope of the first version.
- Important: it adds real value and will come in later releases.
- Nice to have: useful, but to be reassessed once the app is in use.
Prioritisation is the best tool you have for controlling budget and timescale.
4. The data
- What information does the app handle: customers, products, jobs, documents, amounts?
- Where does it come from today? Do you need to migrate history (files, an old system)?
- Is there personal or sensitive data? If so, who may see it, and how long should it be kept?
- Which documents must the app produce: quotes, reports, accounting exports?
5. Integrations
This is often the most underestimated part. List the tools the app must exchange data with:
- accounting or invoicing software;
- an existing ERP, CRM or management tool;
- email and calendars;
- online payment, banking;
- your website or online shop;
- artificial intelligence services.
For each: what information flows, in which direction, how often? Does the software have an API? The answers weigh heavily in the estimate.
6. Technical constraints and security
- Hosting: in France, in the EU, on your own premises?
- Authentication: individual accounts, sign-in through the company directory, two-factor?
- Access rights: who sees and changes what?
- Offline use: must the app work without a connection?
- Accessibility: users with disabilities, usage constraints (gloves, sunlight, noise)?
- Volumes: expected numbers of users, documents, transactions.
7. Budget, timeline and what comes after
Give a budget envelope, even a rough one: it lets the supplier propose a suitable solution rather than an ideal one out of reach. State the real deadlines, and think about the long term:
- who will administer the app day to day?
- what level of maintenance and support is needed (fix times, updates)?
- who will own the code and the data?
Common mistakes
- Describing the solution instead of the need. “We need a button that exports to Excel” often hides a real need (“the accountant must get the month’s sales”) that can be met differently, and better.
- Giving everything the same priority. Without priorities, the supplier prices everything, the budget balloons and the first version arrives too late.
- Forgetting a user profile. The end customer, the accountant, the person covering during holidays: each has needs that shape the design.
- Neglecting data migration. Importing ten years of history from mismatched spreadsheets is a project in itself.
- Ignoring the aftermath. An app lives on: without planned maintenance, it degrades with every system update.
- Copying a competitor. Inspiration helps; reproducing a tool designed for another organisation rarely does.
How the brief turns into a plan
Once the brief exists, a good supplier turns it into something you can act on: a short list of journeys for the first version, clickable mock-ups to validate them with users, a technical architecture that covers the integrations and security requirements, and a phased plan with a price for each phase. If a quote arrives without questions about your users, your data or your integrations, treat it with caution: the supplier has probably not read the brief closely.
A template outline
- Context and measurable objectives
- Users and main journeys
- Prioritised features (essential, important, nice to have)
- Data and documents
- Integrations with existing tools
- Technical constraints, security, hosting
- Budget, timeline, maintenance and ownership
A few well-filled pages are enough. Add examples: screenshots of your current spreadsheets, documents produced by hand, apps you find well made. They are often worth more than long descriptions.
Not sure where to start?
That is common, and not a problem. A scoping workshop with a supplier lets you build the document together: you start from your concrete pain points, sketch the journeys, set priorities and end up with a clear scope and quote. It is the first step of our software development projects, and often the most useful one.
Frequently asked questions
Does the brief need to be very detailed?
No. It must be precise about objectives, users, priorities and constraints. The detail of screens and rules is built afterwards, through mock-ups and iterations.
Is a brief needed for a small app?
Yes, even a single page. It is what ensures everyone is talking about the same thing, and what makes a reliable quote possible.
Who should write the brief?
Ideally the client, with the future users, possibly supported by the supplier in a workshop. A document written only by the supplier risks reflecting their vision rather than your needs.
Can we change our minds during the project?
Yes, and that is normal. An iterative approach lets priorities be adjusted based on real use; the brief then serves as the reference for measuring the impact of each change.
The Step By Step studio in Ajaccio, Corsica, helps you shape your requirements in a free first conversation. Tell us about your project.