A bespoke web application brief does not need to describe every screen or settle every technical decision. Its job is to explain the business process clearly enough for the right questions, boundaries and priorities to emerge.
If the requirement involves staff, customers, jobs, documents, approvals or reporting, a useful brief should focus on how the work happens now and what needs to improve. That gives a developer the context needed to shape a suitable bespoke web application, rather than starting with a disconnected list of features.
Start with the problem, not the proposed software
Open with a short explanation of the business process. Describe who is involved, what they are trying to complete and where information currently moves between people or systems.
Useful examples might include a job moving from enquiry to completion, a document passing through review and approval, or a customer needing to see progress without requesting an update. The aim is to show the sequence of work and where it becomes difficult to follow.
Include the reason for considering a bespoke application. That may be repeated administration, inconsistent records, limited visibility or a process that no longer fits comfortably inside general-purpose tools. Keep this factual and specific to the organisation.
Describe the users and their responsibilities
List the people who will use the application and explain what each group needs to do. A role is more useful when it is described through responsibilities rather than a job title alone.
The brief could cover:
- Who creates, reviews, updates and closes records.
- Which users work in an office, on site or remotely.
- Whether customers, suppliers or other external users need access.
- Which information each role may view, change, approve or download.
- Who manages users, permissions and important settings.
These details help separate genuine user journeys. They also reveal where the same information should be presented differently depending on the person using it.
Map the workflow in plain English
Write down the main stages of the process from beginning to end. Do not worry about technical terminology. A numbered sequence, simple diagram or worked example is often enough.
For each stage, note what starts it, who is responsible, what information they need, what decision is made and what happens next. Include exceptions that occur regularly, such as rejected work, missing evidence, reassignment or a customer requesting a change.
It is also helpful to distinguish the first useful release from later ideas. A focused first version can support the essential workflow while leaving sensible room for continued development.
List the records and documents involved
A web application is usually organised around related records. These might include customers, sites, jobs, tasks, staff, photographs, documents, notes, certificates, approvals or messages.
For each important record, explain what information it contains, where that information comes from and how long it remains useful. Identify any existing spreadsheets, databases or file stores that may need to be imported, retained or connected.
If personal information is involved, state what is genuinely required and who should have access to it. The Information Commissioner’s Office explains that data protection should be considered at the design stage and throughout a system’s lifecycle, with personal information limited to what is necessary for its purpose.
Explain permissions, evidence and audit needs
Different access levels should be described early. The brief should identify actions that need tighter control, such as approving work, changing key details, downloading sensitive documents or managing other users.
Where a reliable history matters, explain what needs to be recorded. That could include status changes, approvals, document versions, timestamps or the person responsible for an action. The right level of history depends on the process, so describe the operational need rather than prescribing a technical solution.
Identify integrations and existing systems
List any services the application may need to work with, including email, payments, accounting, file storage, calendars or an existing customer system. Note which tools are essential to the workflow and which would simply be convenient.
Include the name of each service, what information should move between the systems and which system should remain the main source of truth. Access to a suitable API, the reliability of that service and the ongoing dependence it creates can then be assessed during discovery.
Define reporting and notifications
Reports should answer a real question or support a decision. Instead of asking for a dashboard in general, describe what a manager needs to know, how often they need it and which records provide the answer.
Do the same for notifications. Explain the event that should trigger a message, who should receive it and what they need to do next. This keeps alerts useful and avoids building communication around assumptions.
Include accessibility, security and data protection
Accessibility, security and privacy should be requirements from the start, not checks left until the final stage. W3C recommends incorporating accessibility from the beginning of a project and evaluating it throughout development. UK guidance from the ICO and the National Cyber Security Centre takes a similar lifecycle approach to data protection and secure software development.
The brief does not need to specify every control. It should, however, identify the types of users and information involved, any known legal or contractual requirements, important devices and environments, and any actions that would cause significant harm if performed incorrectly.
Describe devices, locations and working conditions
Explain where people will use the application and what that environment is like. A workflow used on a phone at a busy site has different interface needs from one used mainly on a large office screen.
Mention expected devices, browsers, connection limitations and whether users need to upload photographs or documents while away from a desk. These details help testing reflect real use.
Set out launch, migration and ongoing ownership
Describe what needs to happen before the application becomes part of normal operations. This may include importing existing data, testing representative workflows, training users, preparing guidance and deciding who can approve launch.
Name the person or team responsible for the process after launch. Also explain how issues, changes and future features should be handled. An application normally develops alongside the business, so ongoing ownership matters as much as the first release.
A practical checklist for the first conversation
A useful initial brief should answer these questions:
- What business process needs support?
- Who uses it, and what is each role responsible for?
- What are the main stages, decisions and exceptions?
- Which records, documents and existing data are involved?
- What permissions, approvals and history are required?
- Which external services may need to connect?
- What reporting and notifications are genuinely useful?
- What accessibility, privacy and security requirements are known?
- Where and on which devices will people use it?
- What belongs in the first release, and what can wait?
- Who owns the process and the application after launch?
A rough outline is enough to begin
A strong brief creates a shared understanding, but it does not need to solve the project before discovery begins. If the current process is still spread across documents, inboxes and spreadsheets, the related guide on planning a bespoke application when spreadsheets are no longer enough can help identify the first workflow to map.
CH Digital designs and develops bespoke web applications for businesses in Derby and across the UK. A plain-English description of the process, users and information involved is enough for a useful first conversation.
Sources
Information Commissioner’s Office: Data protection by design and by default
W3C Web Accessibility Initiative: Introduction to Web Accessibility
National Cyber Security Centre: Secure development and deployment guidance