How long should a software project brief be?

One to two pages is enough for a first conversation with a development agency. The brief is not a specification. Its job is to describe the problem, who has it, what the software must do for them, the systems it has to connect to, and the budget and date you are working towards. Detail comes later, in discovery, once a vendor has asked the questions your brief raised.

Should a software brief include the technology stack?

Only if you have a real constraint, such as an existing system the new software must run inside, a platform your IT team already supports, or a rule from a customer or regulator. Otherwise leave it out. Naming a language or framework you read about turns a brief into a prescription, and a good vendor will spend the first call talking you out of it instead of talking about your users.

What is the difference between a project brief and a requirements document?

A brief describes the outcome you want and the constraints around it, in plain language, before anyone has been hired. A requirements document describes how the software will behave in detail, screen by screen and rule by rule, and is usually written with the development team during discovery. Writing the second one before you have a team tends to lock in decisions that nobody has tested yet.

Do I need to state a budget in a software brief?

Yes, at least as a range. Without a budget, vendors either guess or quote the most complete version of what you described, and the quotes you receive will not be comparable. A range lets each vendor propose what fits inside it and say what would not. If you genuinely do not know, say so and ask for a phased estimate, with the smallest useful first release priced separately.

How to Write a Software Project Brief

A software project brief is a one or two page document that tells a development team what problem you are solving, for whom, what the software has to do, what it has to connect to, and the budget and date you are working within. That is the whole answer to how to write a software project brief. The rest of this post is about doing each part well enough that the quotes you get back describe the same project and can be compared.

Most briefs we receive fail in one of two ways. Either they are a paragraph ("we need an app for our customers") that forces every vendor to guess, so the quotes range wildly and none of them is wrong. Or they are a twenty-page specification written before an engineer has looked at it, full of decisions that will have to be undone. The brief that works sits between those: short, concrete about outcomes, and honest about constraints. It is the input to discovery, not the output of it, and knowing how to write a software project brief is mostly knowing what to leave for later.

The one-page software brief template

Here is the structure we ask for. Each section is a few sentences or a short list. If a section does not apply, say so in a line rather than leaving it blank, so the vendor knows you considered it.

Section	What goes in it	Length
The problem	What is slow, manual, error-prone or impossible today, and what it costs you	3 to 5 sentences
Who uses it	Each type of user, how many, and where (office, shop floor, on the road)	A short list
What must happen	The outcomes, written as things a user can do, in priority order	5 to 12 lines
Must-have versus later	Which items the first release needs and which can wait	Two lists
Systems and data	Existing software it must connect to, data it must import, where that data lives	A list
Constraints	Regulation, security rules, devices, languages, accessibility, deadlines tied to events	A list
Budget and timeline	A range for each, and what drives the date	2 to 4 sentences
Success	How you will know it worked, three months after launch	2 to 3 sentences
Out of scope	Things people might assume are included that are not	A list

That is the complete software brief template. A brief that covers all nine sections honestly, even roughly, beats a polished document that skips three of them. Guides on how to write a software project brief often add sections for vision and background; in our experience they are the parts vendors skip.

Describe what users will experience, not the technology

The most useful lines in a project brief for a development agency are written from the user's side. Compare two ways of describing the same requirement:

"Build a React dashboard with a PostgreSQL backend and a REST API for the mobile app."
"A branch manager opens one screen in the morning and sees yesterday's sales, today's bookings and any stock that is running low, without calling head office."

The first tells the vendor which tools you have heard of. The second tells them what the software is for, which is what they need to estimate it. It also leaves the engineering decisions to the people who will have to live with them.

Write each outcome as "a [type of user] can [do something] so that [result]". Eight to twelve of these, in priority order, describe most business applications well enough for a first estimate. If you cannot write one for a feature, that is useful information too: it may not be a feature.

Technology belongs in the brief only when it is a genuine constraint. "It must run inside our existing Microsoft 365 environment" is a constraint. "We want it in Python" usually is not.

Must-have versus later: the section that stops scope creep

Every brief should split its outcomes into two lists: what the first release needs to be useful, and what can follow once people are using it. This is the single most effective part of how to write a software project brief that gets accurate quotes, because it tells each vendor what to price and what to merely plan for.

A useful test for the first list: if this feature were missing on launch day, would you still switch off the old process? If yes, it is a later feature. Our post on what an MVP costs and what you are paying for uses the same test, because the smallest useful release is the one you can learn from fastest.

Be strict here. A first release with six must-haves and a clear list of eight later features will be quoted more accurately, built faster and launched sooner than one with fourteen must-haves. The later features do not disappear. They get built with the benefit of real usage.

Integrations, data and compliance: flag the constraints early

Ask any engineer where estimates go wrong and they will name the same three things. None of them are visible in a screen mockup, which is why they belong in the brief.

Systems the software must connect to

List every system the new software must talk to: accounting, CRM, payment provider, warehouse, payroll, a supplier's portal, a government service. For each one, say whether it has an API you have access to, and whether anyone on your side has used it. "Our accounting package" and "a 2009 stock system with no documentation" are very different amounts of work, and the vendor cannot tell which you have unless you say.

Data that already exists

If the new software replaces something, its data has to move. Say what exists, roughly how much, where it lives and whether it can be exported. Migration is routinely the most underestimated part of a project, and the part most likely to be missing from a cheap quote. Flagging it in the brief forces every vendor to price it.

Rules you have to follow

Payment card data, health records, children's data, personal data under GDPR or similar laws, accessibility obligations for public bodies, audit trails your customers demand: each adds requirements that are cheap to design in and expensive to retrofit. You do not need the detail. "We handle patient appointment data in the UK" is enough for a vendor to know what questions to ask.

Be honest about budget, timeline and who decides

Most advice on how to write a software project brief skips budget entirely, which is odd, because it is the line vendors look for first. Vendors cannot quote well against an unknown budget. Without one they guess at the version you can afford, or quote the complete version and lose you on price, or quote low to win and recover the gap in change requests. None of those is good for you.

Give a range. "Between X and Y for the first release, with a separate ongoing budget for support" lets each vendor propose what fits and say what would not. If you have no idea what the range should be, say so and ask for a phased estimate with the smallest useful release priced on its own. Read custom software versus off-the-shelf for a small business before you set the range, because sometimes the honest answer to a brief is that you should not build at all.

Treat dates the same way. If the deadline is tied to a trade show, a contract start or a regulatory change, say which. A date with a reason is something a vendor can plan around, including by proposing a smaller first release. A date without a reason is treated as a wish.

Finally, name the decision-maker. One person on your side who can answer questions and approve work within a day or two does more for the timeline than almost any technical choice. If approvals go through a committee, say so, because it changes how a sensible team plans the work.

What to leave out of a software project brief

Any honest guide to how to write a software project brief spends as long on what to leave out as on what to include, because restraint is what keeps the document useful. Leave out:

Screen designs. A rough sketch of one key screen helps; a full set of mockups locks in decisions nobody has tested. Design is part of the work you are buying.
A technology list, unless it is a genuine constraint.
Your own hour or day estimates. They anchor the vendor to your guess instead of their experience.
Every feature anyone has ever suggested. Put the long tail in the "later" list or leave it out.
"Like Uber but for X." It tells the vendor almost nothing about your users. Describe your users.
Legal boilerplate. Confidentiality and IP terms belong in the contract. The one useful thing to state is that you expect to own the code, which is our standard position on every custom software project we take on.

If the brief is still longer than two pages after these cuts, it is trying to be a specification. Move the detail to an appendix and keep the brief itself short.

A software project brief example, before and after

Before: "We need a booking system for our clinics. It should be modern and easy to use, work on mobile, and integrate with our existing systems. Please quote."

After: "Three physiotherapy clinics take bookings by phone, which ties up reception for most of the morning and causes double bookings when the paper diary and the spreadsheet disagree. We want patients to book and reschedule online, reception to see all three diaries in one place, and reminders to go out automatically. Patients are mostly over fifty and book from a phone. It must connect to our practice management system (it has an API; our IT contractor has credentials). Bookings for the next twelve weeks need importing from the spreadsheet. We handle patient names and appointment reasons, so UK GDPR applies. Payments stay as they are for now. Budget range for the first release is [range], with support budgeted separately. We want to be live before the January new-patient season. Later: online payment, a waiting list, SMS confirmations."

The second version is under two hundred words and every vendor who reads it will quote the same project. It also contains the three things an engineer most needs to know early: an integration, a data migration and a regulation. That is the whole case for learning how to write a software project brief properly: an afternoon of writing saves weeks of back and forth.

Send the brief and get a comparable estimate

Once you know how to write a software project brief, the last step is simple: send the same brief to every vendor you are considering and ask each for a written approach and estimate against it. The quotes will differ, but for reasons you can see: one includes migration, one proposes a smaller first release, one prices a support retainer. That is a comparison you can actually make. For the long-term reason a clear brief matters, read why small software changes take so long: decisions written down once are decisions nobody has to re-derive later.

If you have a brief, or half of one, book a free 30-minute discovery call. A senior engineer will talk it through with you and point out anything missing, and we will send a written approach, timeline and estimate within two business days.

How to write a software project brief that gets you accurate quotes