A brief does not need to design the solution for the development team

You do not need to know which framework, database or cloud provider should be used. A good brief explains the business context, desired outcome, users, process, first-release priorities, constraints and existing systems. Technical design follows from this information.

What to include

1. Business background

Describe the company and current operating situation in a few sentences.

2. Current problem

Use concrete examples: lost leads, slow quotations, repeated data entry, no shared history, poor status visibility or an unmanageable website.

3. Business objective

Replace vague goals such as “make it modern” with observable outcomes: every lead has an owner, customers can request appointments online or administrators can update content without code changes.

4. Users and roles

List visitors, customers, sales users, managers and administrators, together with the actions they need to perform.

5. Main user journey

Describe a typical process step by step. The main path is enough to start a productive technical discussion.

6. Must-have, important and future features

Separate essential MVP capability from later improvements and unvalidated ideas.

7. Explicit non-goals

State what the first release will not include, such as online payment, a native app or historical data migration. Clear boundaries protect time and budget.

8. Existing systems and integrations

List websites, hosting, CRM, ERP, billing, ecommerce, calendars, email, payments and available APIs. Explain which information needs to move and in which direction.

9. Data and privacy

Identify personal, health, financial, confidential, document, image or location data so risk can be considered from the beginning.

10. Content and design

Clarify who supplies copy, images, logo, product data and translations, and describe the desired qualities rather than simply naming another website.

11. Timeline and decisions

Include fixed events, approvers, feedback times and content-delivery responsibilities.

12. Budget range

A range allows the solution to be prioritised realistically. It is not an instruction to spend the entire amount.

13. Operational expectations

State business criticality, usage hours, response-time needs, monitoring, backups and ongoing development requirements.

14. Acceptance criteria

Describe observable outcomes, such as a successful quotation request, correct administration workflow and permission protection.

Copyable brief template

Project name:
Company and business background:
Current problem:
Desired outcome:
Target users and roles:
Main user journey:
Essential MVP features:
Later features:
Explicit exclusions:
Existing systems and integrations:
Types of data processed:
Content and brand status:
Target launch or deadline:
Decision-maker and contact:
Budget range or priority:
Operations/SLA requirement:
Other important notes:

The BT Digital perspective

We do not expect clients to write a technical specification. That is a shared professional task. A clear brief ensures that the conversation starts from the business objective rather than from a preselected technology.

The clearer the problem and the boundary of the first release, the more realistic the proposal, timeline and implementation can be.