How to Write a Brief for a Web App or Software Project

Why the brief matters

When a software project goes over budget, the cause is rarely the code itself. More often, the people involved pictured different things at the start. A brief does not have to be long or technical. Its job is to make sure that you, your team and any developer you talk to share the same picture of the problem, the people involved and what success looks like.

A good brief also makes quotes comparable. If every developer reads the same document, the differences between their proposals tell you about their approach, not about what they guessed you wanted. Our guide on how to choose a web developer covers what to do with the proposals once they arrive.

Start with the problem, not the features

It is tempting to open a brief with a list of features: a dashboard, a login, a calendar, notifications. Features are the answer; start with the question. Describe:

• What happens today: the process as it works now, including the spreadsheets, emails and phone calls involved.
• What goes wrong: where time is lost, where mistakes happen, what customers complain about.
• What it costs you: hours per week, missed orders, slow responses. Rough numbers are fine.
• What "better" looks like: the outcome you would notice if the project worked.

A developer who understands the problem may suggest a simpler solution than the one you had in mind, sometimes an existing tool rather than custom software. That is worth knowing before you spend anything.

What a good brief covers

• Background: your business in a few sentences, and why this project now.
• The problem and the goal: as above, in plain words.
• Users: each type of person who will use the system (customers, staff, managers, partners) and what each needs to do.
• Key workflows: the three to five journeys that matter most, step by step.
• Data: what information the system stores, where it comes from today, and any existing data that has to be imported.
• Integrations: the tools it must connect to (CRM, accounting, payments, email, calendars), with their names.
• Platforms: web, phone, tablet; whether people will use it at a desk or in the field; whether it must work offline. If you are unsure whether you need an app, read mobile app or web app? How to decide.
• Constraints: deadlines that really matter (and why), budget range, rules you must follow such as data protection, and who signs off decisions.
• What success looks like: how you will know, three or six months after launch, that it was worth it.

Describing features as user stories

A simple, widely used format for describing features is the user story:

As a [type of user], I want to [do something], so that [I get some benefit].

For example: "As a customer, I want to see the status of my order, so that I do not have to call to ask." Or: "As an office manager, I want to approve leave requests from my phone, so that people are not waiting for me to be at my desk."

The "so that" part is the most useful. It explains why the feature exists, which lets a developer suggest a better way to reach the same goal. Ten to twenty good stories describe most first versions better than a long specification.

Deciding what goes in the first version

Few projects can or should build everything at once. Sort your user stories into three groups:

• Must have: without these, the first version is not useful to anyone.
• Should have: important, but people can manage for a few weeks without them.
• Could have: nice ideas to revisit once real users are on the system.

Be strict with the first group. A small first version that real people use within weeks teaches you more than a large one that takes a year, and the feedback usually changes what belongs in the second group. This is how we approach web application development: one workflow done well, shipped early, then extended.

A brief template you can copy

1. About us: who we are, what we do, how many people will use the system.
2. The problem: how the process works today and what goes wrong.
3. The goal: what will be better, and how we will measure it.
4. Users: each user type and what they need to do.
5. Key workflows: the most important journeys, step by step.
6. User stories: grouped into must, should and could have.
7. Data and integrations: what we store, what we import, which tools it connects to.
8. Platforms: web, mobile, offline needs.
9. Constraints: deadline and why, budget range, compliance, decision makers.
10. Examples: tools or apps we like, and what we like about them.
11. Open questions: what we are unsure about and would like advice on.

Two to four pages is plenty. Screenshots, photos of whiteboards and sample spreadsheets are often clearer than paragraphs.

Common mistakes

• Prescribing the technology without a reason. Say what it must do; leave how to the developer, unless you have a real constraint (an existing system, an in-house team that must maintain it).
• Listing every possible feature as equally important. Everything urgent means nothing is.
• Leaving out the awkward cases: refunds, cancellations, users who leave, data that is wrong. These are where most of the real work is.
• Forgetting the admin side. Someone has to manage users, content and settings; their screens are part of the project.
• Skipping life after launch: hosting, updates, support and who on your side owns the system.
• Hiding the budget. A range helps a developer propose something realistic instead of guessing.

Frequently asked questions

Do I need technical knowledge to write a brief?

No. The most useful brief describes your business problem, your users and your workflows in plain language. A good developer will translate that into technical decisions and ask about anything that is unclear.

How detailed should the brief be?

Detailed enough that someone outside your business understands the problem and the main workflows; short enough that people read it. Two to four pages, plus examples, works for most projects.

Should I include a budget?

Yes, even a range. Software can be built in very different ways for the same goal, and the budget tells a developer which approach to propose. Without it, quotes are hard to compare.

What if I do not know what I need yet?

Write down the problem and the people involved, and say that you are unsure about the solution. Many developers offer a short discovery phase to turn that into a plan before committing to a full build.

Will the brief change during the project?

Almost certainly, and that is fine. The brief sets the direction and the first version; what you learn from real users shapes what comes next. Agree with your developer how changes are discussed and priced.

Have a brief, or the start of one? See how we approach web application development and mobile apps, or email info@creahive.com.