A project brief is a short description of what you want to change in your business and why. It is the starting point for every conversation with a developer, and it does not need to be long or technical.
Many people delay getting in touch because they think they need a full specification first. You don’t. A clear half page is often more useful than twenty pages of features, because it explains the problem the software needs to solve.
What a brief is for
A brief helps the person reading it answer three questions:
- What are we trying to change? The problem or opportunity in your business.
- Who is it for? The people who will use the software, such as customers, staff or both.
- What would a good result look like? How you will know the project worked.
With those answers, a developer can ask better questions, suggest the right kind of solution and give you a realistic idea of scope and cost.
What to include
1. The problem in your own words
Describe what happens today and what is not working. For example: “Customers book appointments by phone. Staff write them in a paper diary, and we often double-book.” This tells a developer far more than “we need a booking system.”
2. Who will use it
List the groups of people involved and what each one needs to do. Customers might need to book and pay. Staff might need to see the day’s schedule. A manager might need a weekly summary.
3. What you already have
Mention your current website, tools and data: a WordPress site, a Shopify store, spreadsheets, a CRM or accounting software. Existing tools often decide what can be reused and what needs connecting.
4. What success looks like
Keep it practical. “Customers can book without calling us” or “we stop copying orders between two systems” are good examples. You do not need numbers, but if you have them, share them.
5. Limits and preferences
Share any budget range, a date that matters (such as a product launch or a busy season) and anything you must keep, such as your brand or an existing system. If you don’t know the budget yet, say so.
6. What you are unsure about
This is the most underrated part. Write down your open questions: “Do we need an app or is a website enough?” or “Can this connect to our accounting software?” Good developers will answer them honestly.
What to leave out
- Technology choices, unless you have a real reason for them. Let the developer recommend tools based on your needs.
- Every possible feature. List the essentials first. Extra ideas can go in a separate “later” list.
- Confidential details, until you have agreed on a non-disclosure agreement (NDA) if you need one.
A template you can copy
Our business: one or two sentences about what you do.
The problem: what happens today and what is not working.
Who will use it: the groups of people and what each needs to do.
What we already use: website, tools, data.
A good result would be: how you will know it worked.
Limits: budget range, important dates, things we must keep.
Open questions: what we are unsure about.
What happens after you send it
A good developer will read your brief, ask follow-up questions and then suggest a scope: what will be built first, what is included and what it will cost. You should receive this in writing before any work begins, so you can compare options and decide without pressure.
If you would like us to read your brief, you can send it through our project form. A few sentences is enough to start.