At the start of a project we often hear: “I’m not sure how to describe it exactly.” That is perfectly fine. A brief doesn’t have to be written by a programmer, doesn’t have to be technical and certainly doesn’t need dozens of pages. Its job is to help developers understand your business, your people and your goals so they can propose a solution that makes sense. Technical details can be added later; understanding the problem cannot.
In this article we walk you through an approach that works well for us. You don’t have to cover every point down to the last detail. Each of them, however, saves time on both sides and reduces the risk of ending up with an app that works but doesn’t solve the main thing.
Why a good brief matters so much
Software development is a chain of decisions. What the database will look like, which screens the app will have, what happens when a user makes a mistake, which systems it will connect to. Every one of those decisions rests on assumptions about how your company works. When the assumptions are wrong, the mistake often only shows up once real people start using the app. Fixing it then takes far more effort than if it had been caught at the start.
A good brief is therefore not just a basis for estimating effort. It is a shared foundation that you and the developers keep coming back to throughout the project. It helps you decide what takes priority, what can wait and what doesn’t belong in the project at all.
Start with the problem, not the features
The most common mistake is to start with a list of features: “We want a login, an orders table, an Excel export and notifications.” Such a list is useful, but it doesn’t say why you need those features. Instead, first describe what is bothering you today. For example: “Orders arrive by e-mail, we copy them into a spreadsheet by hand and now and then one gets lost or is handled twice.”
A sentence like that tells a developer much more. They know the key thing is reliability and visibility of each order’s status, not the form itself. They can suggest that orders flow into the system automatically, that each one has a clear status and that everyone can see who is working on it. It often turns out that the best solution looks different from what you originally expected, and is simpler too.
These questions can help:
What do you do manually, repeatedly and reluctantly today?
Where do errors, delays or misunderstandings occur?
What do customers or colleagues complain about?
What would happen if you left the problem unsolved for another year?
Describe who will use the app
A customer on a phone, a sales rep in the field and an accountant at a desk have completely different needs. The customer wants to complete an order quickly without unnecessary registration. The sales rep needs to see data even with a weak signal. The accountant appreciates clear exports and the certainty that the numbers add up. If these groups are missing from the brief, developers will have to guess.
List all user groups and for each one write down:
what they need to do in the app and what they should not see,
how often they will use it, whether daily or once a month,
on which device and in what environment, for example in the office, in a warehouse or on the move,
how comfortable they are with computers.
Permissions, design and technology all follow from this. An app for warehouse staff wearing work gloves will have big buttons and minimal typing. An internal tool for an analyst can handle denser screens full of data.
Write down the main scenarios
A scenario is a short story: who does what, why, and how it ends. Unlike a list of features, it shows the connections. For example:
A customer picks a time slot on the website, pays for the booking online and receives a confirmation by e-mail.
The receptionist sees all bookings for the week and can move an appointment. The customer is notified of the change automatically.
Every Monday the owner receives a summary of last week’s sales and occupancy.
Five to ten scenarios like these are usually enough to make it clear what the app should do. Don’t forget the less pleasant situations either: what if a customer cancels a booking, a payment fails or the receptionist deletes an appointment by mistake? Exceptions tend to be the most laborious part of a project, so it pays to talk about them early.
For each scenario, it helps to note how it is handled today. Even a description like “we send it to each other by e-mail and then someone retypes it” is valuable, because it shows where the data comes from and who works with it.
Decide what is essential and what would be nice to have
Ideas multiply while you prepare a brief. That is good, but not everything has to be in the first version. Split your requirements into three groups:
Essential: what the app makes no sense without and cannot be used without.
Next version: what helps a lot but can be added after launch.
Ideas for the future: what would be interesting but nobody needs yet.
The first version should contain only the first group. You will reach users sooner, start saving time or earning money earlier, and can steer further development by real feedback rather than guesses. Very often, features that seemed crucial at the start turn out to be unused, while a need appears that nobody had thought of.
Don’t forget integrations and data
An app rarely lives on its own. Write down what it needs to work with: accounting software, an e-shop, a payment gateway, a warehouse, a CRM, company e-mail or the spreadsheets you use today. For each system it helps to know whether it has an interface for integration (an API), who manages it and whether the app only needs to read data or also write it.
The data you already have is just as important. Will you migrate customers, products or order history into the new app? What format is it in and how clean is it? Data migration is often underestimated, yet whether people embrace the new app frequently depends on it. Nobody wants to start with an empty system when they used to have everything at hand.
Integrations with other systems and data migration are the most common source of surprises, so it is good to know about them from the start.
Think about operations, security and rules
Besides what the app should do, how it should work matters too. Consider these questions:
Who may see which data and who may change it?
Do you handle personal data covered by GDPR, or sensitive business information?
Does the app need to work outside business hours, and how quickly must an outage be resolved?
Do you need to know who changed what and when?
Should the app be in one language only, or in several?
You don’t need to know the answers. It is enough to mention the questions. The developer will then know what to ask and what to account for in the design.
Add examples and materials
A picture often says more than a page of text. Attach anything that shows how things work today or how you imagine them:
screenshots of apps you like, or dislike,
sample documents such as an invoice, an order or a handover report,
a data export or a sample of the spreadsheet you work with today,
a photo of a paper form or a sketch on paper.
The materials don’t have to be perfect. They just need to show reality. Every example like this saves hours of back-and-forth and reduces the risk that both sides imagine something different behind the same word.
Define what success looks like
What should change after launch? Less manual work, fewer errors, faster order processing, more enquiries from the website, a better overview of jobs. When you name the goal up front, you can keep coming back to it during development and decide which features take priority. After launch, you can easily check whether the investment paid off.
Ideally, the goal can be measured somehow, for instance by the time spent on a task or the number of errors. If that isn’t possible, a description will do: “We want the manager to see the status of all jobs on one screen without having to phone colleagues.”
A simple brief outline
If you don’t know where to start, you can use this outline. A few sentences per point are plenty:
Who we are and what we do.
What problem we want to solve and why now.
Who will use the app.
The main scenarios, including exceptions.
What is essential for the first version and what can wait.
Which systems and data the app should work with.
Security and operational requirements.
Examples and materials.
How we will know the project has succeeded.
Deadlines that matter, such as a season or a planned event.
We’ll fine-tune the rest together
A brief is a starting point, not a contract set in stone. In the first consultation we will go through the scenarios with you, add anything that was missed and point out the parts that may be technically demanding. We will propose a solution and a step-by-step plan so that you have something usable in your hands as soon as possible.
If you don’t have a brief yet, that’s fine. Send us a few lines about what you are planning and we will start from there. We are happy to ask the right questions ourselves.