How to write a software brief that agencies can actually price

Three agencies can receive the same brief and return three prices for three different products. One assumes a simple web app. Another includes mobile apps. A third allows for migration, support and administration that nobody mentioned. The spread looks like a pricing problem, but the first problem is often the brief.

Your goal is not to design every screen before hiring a team. It is to make uncertainty visible. A good brief tells an agency what you know, what you are testing and which decisions you expect it to help make. The template below is an editorial framework, not a procurement standard.

Start with the work a user needs to finish#

Write a short account of the current situation: who experiences the problem, when it occurs, what they do today and what a successful outcome would change. GOV.UK’s user-research guidance begins with learning about users and their needs; its discovery guidance also emphasises understanding the problem before committing to a service.^[1][2]

For an illustrative booking product, “help independent tutors confirm lessons without repeated messages” gives a team something to investigate. “Build an Airbnb for tutors” hides the difficult decisions behind a familiar brand. Include the evidence you already have: interview notes, anonymised workflow examples or a manual pilot. Label assumptions explicitly.

Use this software brief template#

Define a complete journey, including the failures#

Follow one user from arrival to a useful result. In the tutoring example, that means finding a suitable tutor, requesting a slot and receiving a confirmed booking. Then write what happens when the tutor declines, the slot disappears or a confirmation email fails. The administration required to resolve those cases belongs in the conversation too.

Separate “must work for the first cohort” from “would improve the product later”. A launch may need a staff member to handle refunds manually. It may not need a configurable refund engine. Both choices should be explicit. Our MVP scope guide helps distinguish a small product from an incomplete journey.

Replace vague features with acceptance examples#

“Secure login” is too broad to estimate consistently. Say which people can create accounts, how they recover access and what each role can see. “Payments integrated” also leaves open questions about failed payments, receipts, refunds and reconciliation. Describe outcomes without dictating implementation where you lack the evidence to do so.

Ask the agency to identify missing cases and propose a shared acceptance process. This is useful disagreement: it surfaces work while you can still change the scope. Record the decisions in the brief rather than allowing separate email threads to become competing specifications.

Expose the dependencies before they become delays#

List every external system and the person who controls access. An integration described as “connect to our CRM” could mean a well-documented API, a restricted account or an unreliable spreadsheet export. Supply sample records stripped of personal information, identify the source of truth and explain what must happen when records conflict.

Also list decisions that only your business can make. Who signs off the content? Who defines cancellation rules? Who provides test users? A delivery date assumes that these inputs arrive. If you are still investigating a critical dependency, commission a bounded discovery or technical investigation before asking for a firm full-build commitment.

Make the commercial response comparable#

Share a realistic budget envelope and distinguish a target launch date from an immovable external commitment. Ask for the proposed team, working cadence, dependencies, change process, hosting costs and post-launch support. Request a separate list of exclusions. A cheaper proposal that omits an essential service is not yet a cheaper solution.

The Cabinet Office’s agile contracting guidance discusses matching commercial arrangements to uncertainty and delivery methods.^[3] For a private project, the practical question is what you are buying: a specified result, a team’s time or continuing capacity. Use our agency pricing comparison to make that distinction before evaluating totals.

Run one clarification round, then choose#

Send the same core brief to each shortlisted team. Collect their questions, decide the answers and share the material clarifications with every bidder. Ask for an updated response against the same version. This makes the process fairer and makes the resulting proposals easier to read.

Finally, examine how the team reasons about the work. Can it explain a narrower first release? Does it flag uncertain assumptions? Does it make handover concrete? A brief is doing its job when it starts a precise conversation about the product you can afford to build and operate. For the next decision, compare an agency with a freelancer against the responsibility your project needs.

A filled-in brief excerpt#

This example is fictional. Its value is the connection between a problem, a release boundary and an observable result. Replace the nouns and assumptions with evidence from your own business. Do not paste the example into an agency brief and treat its scope as validated.

Ask for a structured supplier response#

Have every bidder respond to the same headings: recommended scope, assumptions, named team, milestones, acceptance, price, exclusions, recurring costs and handover. Invite a smaller alternative if the budget does not fit, but ask the supplier to show exactly what changes.

After clarification, issue a dated version and record decisions in one place. If a supplier proposes a different workflow, explain why you accept it and update the criteria. Otherwise, the accepted proposal and the original brief can describe two different products.

The downloadable template below includes both the buyer’s brief and the supplier response. It is deliberately editable plain text, so a team can use it in its own document system. Attach supporting diagrams and research where they help; do not bury the decision in a long unprioritised feature list.

Put this guide to work#

Frequently asked questions#

Sources and methodology#

This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.

1. GOV.UK Service Manual: learning about users and their needs ↗

   Primary guidance on understanding users and existing behaviour.

   Accessed 16 October 2026
2. GOV.UK Service Manual: how the discovery phase works ↗

   Public-service guidance used for its problem-definition principles, not as a startup timetable.

   Accessed 16 October 2026
3. Cabinet Office: Contracting for Agile Guidance Note ↗

   Published guidance, updated 20 June 2023. Its public-sector context differs from a private agency engagement.

   Accessed 16 October 2026

Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.

Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.