When a business asks three developers to quote for "a website" or "an app", it often receives three prices that are wildly different. That is not because someone is cheating – it is because each developer imagined a different project. A clear project brief fixes this. It does not need technical language. It just needs to describe what you want and why.
What is a project brief?
A project brief is a short document, usually one or two pages, that explains:
- who you are;
- what problem you want to solve;
- what the finished product must do;
- your budget range and deadline;
- who will make decisions.
It becomes the shared starting point for everyone involved.
1. Introduce your organisation
Write a few sentences about your business: what you do, where you operate, how many staff or branches you have and who your customers are. This helps the developer understand your context – a school, a hospital, a logistics company and a fashion shop all have very different needs.
2. Describe the problem, not just the solution
Instead of only writing "We need an app", explain the problem:
- "Customers call us all day to ask about order status."
- "Our branches send stock figures by WhatsApp, and they are often wrong."
- "We lose bookings because people cannot see availability outside office hours."
A good developer may suggest a simpler or cheaper solution once they understand the real problem.
3. List the main features
Write the features as plain sentences, starting with the most important:
- Customers can create an account and see their order history.
- Staff can add and edit products with prices and photos.
- Customers can pay with mobile money.
- Managers receive a daily sales report by email.
Mark each feature as must have, nice to have or later. This makes it easy to adjust the scope if the budget is tight.
4. Who will use it?
List the types of users: customers, cashiers, managers, administrators. For each, note what they need to do. Mention any languages required (for example English and Kiswahili) and the devices people will mainly use.
5. Share examples
Include links to websites or apps you like – and explain what you like about them. It might be the layout, the booking process or the colours. Examples you dislike are useful too.
6. Mention existing systems and content
Do you already have a domain, hosting, a logo, an accounting package or customer data in spreadsheets? Say so. Connecting to existing systems or importing data can affect cost and time.
7. Be honest about budget and timeline
Many people avoid sharing a budget, fearing the developer will simply quote that amount. In practice, a budget range helps developers propose a realistic solution instead of guessing. Also explain why your deadline matters – a launch event, a new financial year or a marketing campaign.
8. Name the decision makers
Projects slow down when nobody can approve designs or answer questions. Name one main contact who can make decisions quickly, and say who else needs to approve major choices.
9. Think about life after launch
Ask about hosting, maintenance, security updates, backups, training and support. Who will own the code and the domain? What happens if you want to add features next year?
A simple brief template
Copy these headings into a document and fill them in:
- About our organisation
- The problem we want to solve
- Main features (must have / nice to have / later)
- Users and languages
- Examples we like and dislike
- Existing systems, data and content
- Budget range and deadline
- Main contact and decision makers
- Support and maintenance expectations
What to expect next
With a good brief, developers can ask better questions and give quotes you can compare fairly. Expect a professional team to come back with questions – that is a good sign. It means they are thinking carefully about your project rather than guessing.
Planning a website, app or business system? Send your brief to Daraja and we will respond with questions and a proposal.