Business systems & integrations

How to brief a web development partner

A strong development brief explains the decision and business outcome before listing screens or technologies.

Reviewed 2026-08-09

Direct answer

The brief should make the current problem, users, required result, dependencies, ownership and acceptance evidence clear enough for suppliers to identify assumptions and risk.

Answer scope

What this page helps you decide.

Who this is for

  • Businesses and agencies preparing to request a proposal.

What is covered

  • Problem and outcome definition
  • Scope and exclusions
  • Access and dependencies
  • Acceptance and proposal comparison

What is not claimed

  • No production credentials in the initial brief
  • No fixed deadline without content and decision owners
01

Describe the current situation

Explain the current platform, users, process and business problem. Include representative evidence such as approved screenshots, sample reports or anonymized records where useful.

Avoid sending customer data or live credentials during initial discovery.

02

Define the required outcome

State what should be different for the customer and staff. Use observable acceptance such as a qualified enquiry appearing with an owner and source—not a vague goal such as “make it modern.”

Separate required outcomes from optional ideas.

03

List users, data and dependencies

Identify customer types, staff roles, records, external systems, content owners and access that the project depends on.

A supplier cannot responsibly estimate an undocumented external system as though it were under their control.

04

State commercial and ownership boundaries

Include target budget, timing, procurement constraints, hosting, licences, source ownership, handover and support expectations.

A range is more useful than hiding the budget and comparing proposals built on different assumptions.

05

Ask for evidence and exclusions

Request relevant approved work, a clear delivery scope, assumptions, exclusions and acceptance plan. Do not require suppliers to disclose private client code, credentials or security-sensitive implementation procedures.

Compare proposals by business fit and ownership—not only feature count.

Questions

Frequently asked questions

Should the brief specify a technology?

Only when there is a genuine platform constraint. Otherwise describe the business requirement and ask the supplier to explain the recommended fit.

How long should a brief be?

Long enough to make the outcome, users, dependencies and acceptance clear. A concise evidence-led brief is better than a long feature wishlist.

Should I include a budget?

Yes, a realistic range helps suppliers propose an appropriate approach and identify when the requested scope does not fit.

Start a conversation

Need help applying this to a real website or system?

Send the current setup and the result you need. I will review the problem and suggest the most practical next step.

Chat on WhatsApp