How to write a website or software project brief in Kenya

Start with your business type, customers, location and current process. Explain the problem with an example: customers ask the same product questions on WhatsApp, staff repeat order details in several spreadsheets or managers cannot reconcile branch stock. Avoid promising an improvement percentage before you have a baseline.

Choose the primary outcome of the first release. For a service website, that could be enquiries containing the customer's required service and location. For internal software, it could be one approved order moving from entry to fulfilment without duplicate entry. Add how you will measure that outcome with records you can actually collect. A clearer outcome makes it easier to challenge a feature that does not help.

Describe customers, staff and administrators separately. A visitor browsing a website does not need the same information or permissions as the person publishing its content. For each role, write a starting situation, the steps needed and the expected result. Include an exception, such as an unavailable item or a rejected approval.

Use a hypothetical shop as an example: a customer chooses a product variant, sees delivery information, places an order and receives a clear status. Staff verify payment, prepare the order and record fulfilment. If one of those steps happens outside the website, state which tool or person handles it. A practical brief can include manual steps rather than pretending every task must be automated.

Group requirements by what must work at launch, what would be useful and what can wait. The essential group should form a complete workflow. Removing the administrator's order view while keeping checkout does not create a smaller usable shop; it creates an operating gap. Ask the supplier to explain dependencies before assigning phases.

Record the reason for each requirement. A language choice, dashboard or loyalty feature may be justified, but the developer needs to know the underlying users and constraints. Include devices, internet limitations and existing business tools. If the only reason is that a competitor has the feature, investigate whether your customers or staff actually need it.

For a website, list approved text, product details, photographs, brand assets and policies, then name who supplies or approves them. Identify which staff should edit pages and whether training is needed. For software, list the data sources, formats and approximate quantities, using anonymised samples when sharing records for an estimate.

Identify external providers and what you already have access to. Safaricom Daraja, for example, makes APIs available for M-PESA integration, but the provider setup for your project still requires checking. Do not label a proposed connection as ready until access and the required workflow are verified. Name who controls the merchant account and who resolves operational discrepancies.

Acceptance criteria should let you and the supplier agree whether a task works without arguing about vague language such as user-friendly or fully functional. Use sample data and an observable result. Include errors and permissions, not just the normal path.

Give a budget range if you have one, including whether it covers ongoing costs. State the deadline and any event or business dependency behind it. Identify approval dates, content availability and the person who can resolve questions. A target date cannot become reliable until the scope and dependencies are understood.

Specify the accounts, documentation, source rights and data exports you expect at handover. Record support requirements, operating hours and who will maintain the system. NIST SSDF is a useful reference for discussing secure development responsibilities; it is not a substitute for agreed project-specific checks. Ask the supplier to identify exclusions rather than assuming a general promise covers everything.

Send the same brief to shortlisted suppliers and ask them to state assumptions, deliverables, milestones, recurring costs and questions. When a recommendation changes the scope, evaluate whether it improves the outcome rather than rejecting it simply because it differs from your original feature list. Keep decisions in a written record that both sides can review.

Use the free template below to draft your first version. For a public website, start with our website design service and website cost guide. For staff workflows or a customer portal, use custom software development. Share the brief with Ken Designers so the next conversation can focus on a workable scope and quotation.