Hiring guide
How to write a project brief
Last reviewed , published by Gjethe
The short answer
A good project brief explains why the project exists, who it's for, what it must do, what already exists, examples you like, systems it must connect to, content status, constraints and a budget range. It doesn't need technical detail; it needs clarity about goals and priorities, so providers can propose the right solution and give comparable quotes.
A clear brief is the single most useful thing you can prepare before hiring a developer, designer or agency. It saves meetings, makes quotes comparable and reduces the risk of building the wrong thing. You don't need to know the technology. You need to explain your goals, users and priorities. This guide gives you a structure and examples.
What to include in a brief
| Section | What to write |
|---|---|
| Background | Who you are and what your business does |
| Goal | What the project should achieve, ideally measurable |
| Audience | Who will use it and what they need |
| Scope | Pages, features or deliverables you think you need |
| Examples | Sites, apps or designs you like, and why |
| Existing assets | Brand, content, current site, data and systems |
| Integrations | Tools it must connect to |
| Constraints | Deadlines you can't move, legal or technical requirements |
| Budget range | A realistic range, even if approximate |
Focus on goals, not solutions
Briefs often jump straight to solutions: “we need an app with a chatbot”. It's more useful to describe the problem: “customers call us every day asking for order status”. That lets providers suggest the simplest effective solution, which might be different and cheaper.
Include how you'll judge success (more enquiries, fewer support calls, faster internal processes) so everyone works towards the same outcome.
Why sharing a budget range helps
Many people hide their budget, hoping for lower quotes. The result is often proposals that don't fit: too ambitious for the money, or too basic for the goals. A range lets providers recommend what to prioritise and what to postpone.
You don't have to give a fixed number. A range and an honest note about flexibility is enough.
Mark features as must-have or nice-to-have
- Must-have: the project fails without it
- Should-have: important, but could follow soon after
- Nice-to-have: valuable if budget allows
- Later: ideas for future phases
Examples make briefs concrete
Links to sites, apps, videos or designs you like, and a sentence on what you like about each, communicate style and functionality far better than adjectives like “modern” or “clean”.
Examples you dislike are just as helpful.
Common gaps in briefs
| Gap | Why it matters |
|---|---|
| Who writes the content? | Content is often the biggest hidden task |
| Who maintains it after launch? | Affects platform choice and support needs |
| What systems exist today? | Integrations drive cost and risk |
| Who decides? | Too many approvers slow projects |
| Languages | Each language adds content and set-up |
A simple brief template
Background: who you are and what you do. Goal: what success looks like. Audience: who will use it and what they need. Scope: pages, features or deliverables, marked as must-have or nice-to-have. Examples: links you like and why. Assets: brand, content and systems that exist. Constraints: fixed dates, legal or technical requirements. Budget: a realistic range. Contacts: who decides.
Filling in these headings in plain language is enough for most web, app and design projects.
Example: vague versus clear
| Vague | Clear |
|---|---|
| We need a modern website | We need a site that generates more consultation requests from small businesses |
| Users should be able to book | Customers book a 30-minute call with one of three advisers and receive a confirmation email |
| It should look premium | We like the calm layout and large photos of these two sites |
| Integrate with our systems | New enquiries should appear in HubSpot with the source recorded |
After you send the brief
Expect good providers to ask follow-up questions. Those questions show how carefully they've read it and often reveal decisions you haven't made yet.
Update the brief with the answers and share the same version with every provider so proposals stay comparable.
Defining success
Success measures turn a brief into a shared goal. Examples include more enquiries from a specific audience, fewer support calls, faster internal processes or more online sales. Even rough numbers help, such as doubling enquiries from organic search.
Measures also help you judge proposals: which approach is most likely to achieve them?
Brief checklist before sending
- Goal stated clearly
- Audience described
- Must-haves separated from nice-to-haves
- Examples with reasons
- Existing assets listed
- Budget range included
- Decision-maker named
Briefs for design and video projects
For design, include where the work will be used, sizes and formats, brand assets and examples. For video, include the purpose, audience, length, platforms, references and available footage.
The same principle applies: goals first, then requirements, then examples and constraints.
Keep the brief alive
A brief isn't only for hiring. Keep it updated as decisions are made during the project, and share it with everyone involved. It becomes a reference for scope discussions and onboarding new team members.
When something new comes up, check it against the brief's goals before adding it.
Frequently asked questions
How long should a brief be?
One to three pages is usually enough. Clarity matters more than length.
Do I need technical knowledge?
No. Describe goals, users and needs; providers translate them into technical solutions.
Should I share my budget?
Yes, as a range. It leads to more useful proposals.
Can a provider help write the brief?
Yes. A free consultation can help shape it, and good providers ask questions to fill gaps.
Should the brief include deadlines?
Include fixed dates that genuinely matter, such as a launch event, and why.
What if requirements are unclear?
Say so. A discovery phase can clarify requirements before a full build.
Should I send the same brief to everyone?
Yes. It makes proposals comparable.
What about confidentiality?
Keep sensitive details out of the first brief or ask providers to sign an NDA first.
Should a brief include design preferences?
Yes, as examples and reasons, not detailed designs. Let the designer propose solutions.
Can a brief be too detailed?
Very detailed technical specifications can limit good suggestions. Focus on goals and requirements rather than implementation.
Should the brief mention competitors?
Yes. Listing competitors and what you like or dislike about them helps providers understand your market.
Do I need a brief for small projects?
Even a few sentences covering goal, audience and deliverables helps avoid misunderstandings.
Can you send us a brief template?
Yes. We can share a template in the free consultation and help you complete it.
Should I include technical requirements?
Include those you know, such as required integrations, hosting rules or security standards; providers can suggest the rest.
Who should write the brief?
The person who owns the project, with input from colleagues who use the result.
Related services
Website Development
Custom business websites on Next.js, React or WordPress.
Mobile App Development
iOS and Android apps, from design to store launch.
Web Applications & SaaS
Portals, dashboards and subscription products.
UI/UX Design
Research, wireframes, prototypes and interfaces.
MVP Development
The smallest product that proves your idea.
Talk it through with us.
Tell us what you need. You get an honest assessment, a clear plan and a written quote. The first consultation is always free.
- What happens next
- 1You tell us what you need
- 2We aim to reply within 24 hours with questions
- 3You get a written quote for your project