How to Brief a Software Agency (So the Quote Is Real)

A vague brief gets a vague estimate, and vague estimates are how projects double. A good brief fits on one page and answers six questions. You do not need to know anything about software to write it.

Why the brief matters more than the agency

Two agencies quoting the same clear brief will land within 20 percent of each other. Two agencies quoting a vague one will differ by a factor of three, and neither number means anything. The brief is the only thing in the process you fully control, and it is where most of the risk is removed or created.

The six sections

1. The problem, in one paragraph

What is wrong today and what it costs you. Not features - the situation. "Our field team fills in paper job sheets, someone types them up on Fridays, invoices go out a week late and we lose about two a month to errors." That paragraph tells a good agency more than a list of thirty features would. It lets them propose the solution rather than price yours.

2. Who uses it and what each of them needs to do

List every type of user - customer, field worker, office staff, manager, director, partner. For each, the three to five things they must be able to do. This is the single biggest driver of cost, as we explain in the web application cost guide, and it is the section most briefs skip.

3. What it must connect to

Every system that holds data the new one will need or produce: accounting, email, calendar, an existing CRM, a supplier portal, a payment provider. For each, say what needs to flow in which direction. If you are not sure whether something has an API, say so; the agency will check.

4. Where the data is now

Spreadsheets, an old system, paper, someone's head. How much of it, and how clean. Attach a real export if you can. Data migration is the item most often missing from a first quote and the one most likely to blow the budget when discovered late.

5. Constraints

Budget range, even a wide one. Deadline, and whether it is real (a trade show) or preferred. Hosting requirements (UK data residency is common and reasonable). Devices - does it need to work on a phone, offline, on site. Compliance obligations specific to your industry.

6. What "done" looks like

Two or three measurable outcomes: invoices out within 24 hours of job completion, zero re-keying, managers can see the week's utilisation on Monday morning. This is how you and the agency will both know the project worked, and it stops scope arguments before they start.

What to leave out

• Technology choices. Unless you have a real constraint (your team already maintains Laravel systems, say), let the agency propose the stack and justify it. Our note on React versus Laravel explains why the choice should follow the requirements.
• Screen designs. Sketches are useful for showing intent; detailed mock-ups lock in decisions before the people who will build it have thought about them.
• Every feature you have ever wanted. Separate must-have from nice-to-have explicitly. A brief where everything is essential gets priced as though it is.

What a good response looks like

A fixed price with a scope document that restates your brief in their words, a phased plan if the project is large, a named person who will run it, a clear statement of who owns the code and where it is hosted, what happens after launch, and a change process with a rate card. If the response is a day rate and an estimate of days, you have been given a way to be billed, not a quote. Our list of questions to ask an agency covers what to probe on the call.

A template

Six headings, one paragraph or short list under each: Problem. Users and what they do. Connections. Data today. Constraints. Done means. Attach a data sample and any sketches. That document will get you comparable fixed quotes from any competent agency, and it takes an afternoon.

An example brief, abbreviated

Problem. We are a commercial cleaning company with 40 staff across 60 client sites. Supervisors record visits on paper, the office re-keys them, clients query invoices because they cannot see what was done, and we lose around two days a month to disputes.

Users. Cleaners (clock in and out at a site, complete a checklist, report an issue with a photo). Supervisors (see today's sites and staff, reassign cover, review checklists). Office (schedule, invoice from completed visits, handle client queries). Clients (see visits completed at their sites, raise issues, view invoices). Directors (utilisation, margin per contract).

Connections. Xero for invoices (out). Existing payroll platform for hours (out). Email for client notifications.

Data. Sites and contracts in a spreadsheet (about 60 rows, clean). Staff records in the payroll platform. No historical visit data worth migrating.

Constraints. Budget £25,000 to £40,000. Cleaners have basic phones and poor signal in some buildings, so it must work offline. UK hosting. Live before the new contract year in April.

Done means. Invoices raised within 24 hours of month end without re-keying. Client disputes down by half. Supervisors can reassign cover from their phones.

That brief, at about 250 words, is enough for a fixed quote. It names five roles (the biggest cost driver), two integrations, offline mobile use (the second biggest), and an outcome to test against. It says nothing about technology or screens, and that is right.

What happens next

A good agency will come back with questions - how many sites per cleaner per day, what a checklist contains, what "issue" means - and then a scoping call. From that comes a scope document and a fixed price. If you are comparing agencies, send them all the same brief on the same day and compare the questions they ask as much as the numbers they return. The agency that asks about your data and your users is the one that has read it.

Mistakes that make briefs worse

• Writing it by committee. One author, then review. Briefs written by five people list five sets of priorities and rank none.
• Describing the current system's screens. The agency needs the process, not a tour of the tool you are replacing and its habits.
• Hiding the budget. Agencies scope to the budget; without one they guess, and the guesses are wide.
• Leaving out the awkward integration. The legacy system with no API is exactly what the quote needs to account for.
• Sending it to ten agencies. Three well-chosen ones give you comparable quotes; ten give you a spreadsheet and no time to read the scopes properly.

If you write one and want a reply within a working day, send it to us. If it is not something we should build, we will say so and tell you what to do instead.