How to brief a software agency: the one-page project brief that gets you comparable quotes

The reason three agencies quote three different prices for the same project is usually not the agencies. It is the brief. A vague brief forces every vendor to guess, and every vendor guesses differently. A good brief fits on one page, takes an afternoon to write, and gets you comparable quotes — and fewer surprises later.

Here is the structure we ask for, why each section matters, and the three things buyers leave out that cause overruns.

The one-page brief: nine sections

1. The business problem (3–5 sentences). What is costing you money or time today, and what should be different when the project is done. Not features — outcomes. “Our 300 dealers e-mail order and warranty questions to a four-person back office; we want them to self-serve and the back office to handle exceptions only.”

2. Who uses it. List the user groups and roughly how many in each: internal staff by team, customers, partners, administrators. Note anything special: external users needing their own logins, partner admins managing their own users, auditors with read-only access.

3. The journeys that matter. Ten to twenty sentences of the form “A [user] can [do something] so that [outcome]”, in priority order. Mark which are essential for launch and which can follow. This list is what vendors price; make it complete rather than detailed.

4. The systems involved. Every system that holds data the software needs or must update: ERP (name and version), CRM, document management, identity provider (Microsoft Entra ID, Google…), e-mail, payment, industry platforms. For each: does it have an API? Is there documentation? Is there a test system? “Don’t know” is a fine answer — it tells the vendor to budget a check.

5. Constraints. Data residency (Switzerland/EU?), security requirements, accessibility, languages, branding, devices (desktop, tablet on the shop floor, phone), offline needs, deadlines that are real (a contract, a regulation, a trade fair) and ones that are preferences.

6. What exists already. Spreadsheets, an old tool, a prototype, a previous vendor’s code, process documentation. Attach or link it. Existing artefacts save weeks of discovery.

7. Budget range and decision process. A range, not a number (our cost guide gives realistic ones) — vendors will propose the scope that fits it. Who decides, by when, and against which criteria. A vendor who knows you will compare on handover quality will write a different proposal than one who assumes you compare on price alone.

8. Timeline. When you would like to start, when something must be live, and how much of your team’s time is available (the most honest timeline driver).

9. What you expect in the proposal. Ask for the same structure from every vendor: included journeys, excluded items, integrations and assumptions, team and location, milestones and payments, change-request process, handover contents, and indicative post-launch cost (see how we structure engagement models). Comparable proposals come from comparable questions.

The three things buyers leave out

The exceptions. Happy paths are easy; exceptions are where the cost is. Who can override a price? What happens when the ERP is down? How are duplicates handled? Five minutes listing “what goes wrong today” saves weeks of change requests.

Who owns it afterwards. Will your IT take the system over, or do you want a retainer? The answer changes how it should be built and documented — and whether you should insist on owning repositories and cloud accounts from day one (you should).

The real decision-maker’s criteria. If the CFO will ask about total cost over five years and the COO about time-to-live, say so. Vendors answer the questions they are asked.

What to do with the proposals

Put them side by side on the nine sections. Differences in price usually trace to differences in sections 3 and 4 — one vendor counted twelve journeys, another eight; one assumed the ERP has an API, another budgeted a file exchange. Resolve those assumptions before you discuss money.

Then ask each vendor two questions that no proposal answers well on paper: “What do you think we have underestimated?” and “What would you leave out of the first release?” The quality of those answers tells you more than the price.

A template you can copy

PROJECT BRIEF — <project name>                     <date>

1. Business problem and desired outcome
2. Users (groups, counts, special cases)
3. Journeys, in priority order (E = essential for launch)
4. Systems involved (API? docs? test system?)
5. Constraints (data residency, security, languages, devices, deadlines)
6. What exists already (links/attachments)
7. Budget range · decision process · decision date
8. Timeline and our available time
9. Required proposal structure

Our project enquiry form follows this structure, and you receive a written assessment within two business days — use it as a dry run for your brief, even if you end up briefing someone else.