Two businesses ask for "a simple website with a booking feature". One receives a quote three times higher than the other. Neither quote is wrong — they simply imagined different projects.
A good brief closes that gap. It does not need to be technical or long. It just needs to answer the right questions honestly.
1. What problem are we solving?
Describe the pain, not the solution. "Customers keep calling to ask if we are open and what we charge" is more useful than "we need a chatbot". The best solution might be simpler than you think.
2. Who will use it?
List the types of users: customers, staff, managers, administrators. Each group usually needs different screens and permissions, which affects scope significantly.
3. What must it do on day one?
Separate must-haves from nice-to-haves. A clear first release keeps budgets realistic and gets you to launch sooner. Everything else can go on a "phase two" list.
A tip: if you are unsure whether something is essential, ask "would we delay launch for this?" If the answer is no, it is probably a nice-to-have.
4. What does success look like?
More enquiries? Less admin time? Fewer errors? Write down what should be noticeably better six months after launch. This guides every trade-off the team makes.
5. What already exists?
Do you have a logo, brand colours, existing content, a domain name, current software, spreadsheets or data that must be moved over? Existing pieces can save time — or create integration work that needs planning.
6. What needs to connect?
Payment providers, email tools, accounting software, maps, messaging platforms — every integration adds work and occasionally ongoing costs. Listing them early avoids surprises.
7. Who will manage it after launch?
Will your team update content themselves? Do you need an admin dashboard? Who handles hosting, security updates and backups? Ownership after launch is just as important as the build.
8. What is your timeline — and why?
A launch tied to a real event (a product release, a new branch opening) is different from "as soon as possible". Sharing the reason helps the team suggest a sensible plan, sometimes by trimming scope rather than rushing quality.
9. What budget range are you comfortable with?
Many people hesitate to share this. But a range helps a good partner recommend the right approach for your money, instead of guessing. It is a conversation starter, not a trap.
Putting it together
You do not need fancy templates. A one or two page document — or even a well-organised message — covering these nine points will make every conversation with a developer faster and more productive.
You will get clearer quotes, more accurate timelines and fewer "we did not know you wanted that" moments. That is real money saved.
Ready to talk about your project? Answer as many of these questions as you can and send them our way. We will help fill in the gaps.
- #project brief
- #budgeting
- #hiring developers
