What Should Be Included in a Software Development Brief?

I get sent two kinds of brief. The first is three sentences in an email: "We need an app for our engineers to log jobs, a bit like Uber but for plumbing." The second is a 40-page document copied from a template someone found online, full of headings like "Non-Functional Requirements" with nothing underneath them. Neither gets you a good quote. The first leaves too much to guess. The second buries the three facts I actually need under a pile of boilerplate.

A brief has one job: let a developer price and plan the work without having to guess. If it does that, it's a good brief, whether it's two pages or twelve. Here's what needs to be in it.

Start with who uses it and what they're trying to do

Not "we need a CRM". Who logs in, and what are they trying to get done each time they do? A sales manager checking pipeline once a week needs something different from a field engineer updating a job status from a van with patchy signal. The roles and their daily tasks tell me more about the actual build than a feature list ever will, because they tell me what the software has to survive: slow connections, interruptions, people who don't want to use it.

The boring details are the ones that decide the cost

Features are the fun part to describe. They're rarely what makes a project expensive. The cost usually comes from the detail underneath.

• Roles and permissions. Is there one type of user, or several with different access? Can a customer see another customer's data, and what's the rule if they shouldn't?
• Integrations. Does it need to talk to your accounting software, your booking system, a payment provider, an existing database? Which ones, and do you already have API access or credentials, or does that need setting up from scratch?
• Data you already have. Is there an existing spreadsheet, an old system, or years of paper records that need importing? Migrating messy existing data is often a bigger job than the new build itself.
• Volume. Are we talking about 50 records a month or 50,000? A system built for a small dataset can genuinely fall over once it grows, which is exactly the kind of problem I've written about with the N+1 query problem, where something that worked fine in testing crawls once real data hits it.
• Edge cases. What happens when a payment fails, a customer cancels halfway through, or two people edit the same record at once? You don't need to solve these yourself, but flagging that they exist saves a lot of back and forth later.

None of this needs technical language. "Two van drivers might both mark the same job complete, what should happen then" is a perfectly good line in a brief.

Say what "done" actually looks like

A feature list tells a developer what to build. It doesn't tell them what success looks like. If the goal is "reduce the time it takes to raise an invoice from 20 minutes to under 2", say that. It changes how the thing gets built and gives both of us something concrete to check the finished work against, rather than a vague feeling of whether it's "good enough".

Be honest about constraints

A budget range, even a rough one, is more useful than none at all. It tells a developer whether to design for a lean first version or a fuller build, and stops you both wasting time on a proposal that's never going to fit. The same goes for deadlines: if there's a trade show, a contract renewal or a regulatory date driving the timeline, say so up front. And if there's anything you must use (an existing hosting setup, a particular payment provider, a system it has to plug into) or must avoid, put that in too. Finding out about a hard constraint halfway through a build is worse for everyone than knowing it on day one.

Don't forget what happens after launch

A brief that stops at "and then it's built" misses a real cost. Who fixes a bug found in month three? Who has admin access if you want to make small changes yourself? Do you want to own the code outright, or is a subscription-style arrangement fine? These questions matter more once the project's live than while it's being built, and I've covered the ownership side in more detail in who owns the code, which is worth checking before you sign anything.

What you can leave out

You don't need technical architecture, a database schema, or a list of frameworks. That's the developer's job to propose, not yours to specify, unless you have a genuine reason (an existing system it has to match, for instance). Padding a brief with jargon copied from somewhere else doesn't make it more useful. It just hides the parts that actually matter.

If you're not sure where to start

Most people writing their first brief aren't missing effort, they're missing a structure to hang the details on. That's the whole reason I built the Software Brief Generator: it walks you through exactly these questions, mostly by picking options rather than staring at a blank page, and turns your answers into a document you can hand to me or any other developer for an accurate quote. A good brief isn't about writing more. It's about answering the handful of questions that actually change the price.