How to Write a Custom Web Application Project Brief

A request such as “we need a dashboard” leaves important questions open. A dashboard might mean a weekly report, a live operations queue, or a tool that changes customer records. Each requires different work.

This guide gives business owners a practical brief they can prepare before speaking to a web application studio. The goal is a useful conversation and comparable proposals, rather than a long technical specification.

Start with a task people struggle to finish

Describe the current process from the first request to the completed result. Name the people involved, the tools they use, and the point where work gets delayed or repeated.

GOV.UK’s discovery guidance recommends understanding users, constraints, and the underlying problem before committing to a solution. Although written for public services, that starting point is also useful for a business project. GOV.UK discovery guidance

For example, “staff spend time searching email for the latest job approval” is more useful than “build a modern portal.” The first statement makes it possible to investigate whether an existing tool, a process change, or custom software fits.

What belongs in the brief?

Section	What to include	Illustrative example
Users	Who performs each task	Coordinator, reviewer, customer
Main workflow	Start, decisions, and final result	Submit a job, review it, confirm approval
Records	Data created or changed	Job reference, owner, status, attachments
Access	Who can view or change records	Customers see their own jobs
Connections	Existing systems and their owners	CRM supplies customer contact details
First release	Essential outcome and exclusions	Approvals included; invoicing deferred
Acceptance	Observable proof of completion	Reviewer can return a request with a reason

These are planning examples, not a report of a KainoLab customer engagement.

Attach a redacted form, spreadsheet, or sample record where possible. Remove personal information and credentials before sharing it. Explain ambiguous labels: “complete” might mean approved, delivered, paid, or archived.

Write acceptance criteria around real situations

An acceptance criterion describes behavior someone can check. “The app should be easy to use” is a goal, but it does not define a test.

A stronger criterion is: “When a reviewer returns a request, the submitter sees the reason and can send a revised version. The original decision remains in the history.”

Include failures as well as normal use. What happens when an upload fails, two people edit the same record, or a customer opens an expired invitation? The first release can handle an exception manually, but that route must be agreed.

For work with approvals, use the approval workflow guide to define decisions and escalation rules.

Include operating conditions early

List the devices and browsers your team actually uses. State whether staff work with poor connectivity and whether customers need help using the service.

Accessibility belongs in planning, design, testing, and ongoing operation. W3C provides guidance for including it across a project rather than leaving it to the end. W3C accessibility planning

Also identify the person responsible for hosting, user support, updates, and data recovery. Those responsibilities affect the project even when the interface is small.

How much detail is enough for a quote?

A useful brief reveals the core workflow and the main unknowns. It does not need to select every library or define every screen.

Ask suppliers to separate confirmed scope from assumptions. A proposal based on clean sample data may change when the actual records contain duplicates or missing identifiers. Record that dependency before treating the price or schedule as fixed.

Compare proposals using the same workflow, deliverables, exclusions, and support expectations. A lower number may cover a smaller result.

Prepare your first conversation

Send the workflow description, a redacted example, the user roles, and your intended release outcome. Add a list of decisions you still need help making.

KainoLab offers web applications and digital tools for operational problems. You can contact the team with that brief, or first review the software handover checklist to define what you will need after launch.