How to Write a Software Brief That Sets Your Project Up for Success

Commissioning bespoke software is one of the bigger investments a growing business will make, and the brief is where that investment starts paying off or starts going wrong. A study by Engprax, which surveyed 250 UK and 350 US software engineers, found that projects with clear requirements before development starts are 97% more likely to succeed. The brief doesn't need to be perfect. But getting a few things right early on makes a massive difference to what you get back.

I run a software development firm in London. We work with SMEs across the UK, and over time I've noticed patterns in the briefs that lead to the smoothest projects. Here's what I'd recommend focusing on.

Lead with the problem, not the solution

The most useful thing you can put in a brief is a clear description of what isn't working today. "Our managers can't see daily sales performance without asking three different people and waiting until Tuesday" gives a development team far more to work with than "I need a dashboard with six charts showing sales data."

The first version explains the pain. The second jumps straight to a fix, which might not be the right one. When you describe the problem, you give your development partner the room to suggest approaches you might not have considered, often simpler and cheaper ones. You're paying for their expertise, so let them use it.

Write about what's slowing your team down, where the bottlenecks are, and what workarounds people have cobbled together. That's gold for a developer.

Describe who'll actually use it

"The system should be user-friendly" is one of the most common lines in software briefs, but it doesn't tell a developer much. User-friendly for whom? A warehouse manager scanning barcodes with gloves on? A finance director who lives in Excel? A customer placing their first order on a phone?

Each of those people needs something completely different. You don't need formal persona documents. A short paragraph about each type of user goes a long way: what their day looks like, what tools they currently rely on, where they get frustrated, and how comfortable they are with technology. That kind of context shapes better design decisions than any feature list.

Be open about your budget

There's a common worry that sharing your budget with a software agency means they'll just spend all of it. I get the concern, but the opposite tends to happen. Research by UK consultancy Equantiis found that organisations disclosing their budget early receive proposals that are 40% more accurate in both scope and cost.

Here's what happens in practice. If we know a client is working with around £40,000, we can design a phased approach: build the core in phase one, add the nice-to-haves later. Without that context, we're guessing. We might propose something far bigger than needed, or strip it back so far it misses the point. A budget range is all it takes to have a realistic conversation. "We're thinking somewhere between £30,000 and £50,000" is plenty.

Prioritise before you write

Pendo analysed 615 software products and found that 80% of features are rarely or never used. That stat is worrying, as it translates to billions in wasted development globally, and it often starts with a brief that treats every feature as equally important.

That is understandable, but before you write a single requirement, try splitting your wish list into four buckets.

1. What must the software do on day one?
   
2. What should it do if budget allows?
   
3. What would be nice but isn't critical?
   
4. What are you explicitly saving for later?
   

In the industry, we call this MoSCoW prioritisation: Must have, Should have, Could have, Won't have (yet).

That simple exercise gives your development partner a clear picture of where to focus, and it protects your budget from being spread too thin.

Get specific on the things that matter most

The difference between a vague requirement and a specific one can save weeks of rework. Compare these two:

Vague: "The system should integrate with our accounting software."

Specific: "When an order is marked complete, the system should create a sales invoice in Xero with the customer name, line items, and payment terms pulled from the customer record. If the sync fails, the admin needs an email notification."

The second version takes a bit longer to write, but it removes ambiguity that would otherwise surface mid-build. You don't need that level of detail on every single requirement, but for the critical ones it's worth the effort. If you want more detail on structuring these properly, I wrote a complete guide to writing a software requirements specification that walks through the process step by step.

Share what you've already tried

If you've previously attempted to fix the problem, whether with off-the-shelf software that didn't quite fit, or a freelancer engagement that stalled, include that in your brief. It's useful context, not a confession. Knowing what hasn't worked helps your development partner avoid the same dead ends and often points towards a better solution.

Keep it to ten pages or less

A brief isn't a full specification. It's the starting point for a conversation. Your development partner should take it and run a proper discovery phase, with workshops, prototyping, and detailed questions, to turn it into a full technical plan. Your job is to give them enough context to start that process well.

Ten pages is a good ceiling. If it's running longer than that, you might be prescribing solutions rather than describing problems, and that's worth stepping back to reconsider.

The UK has some expensive reminders of what happens when projects start without clear communication. Birmingham City Council's Oracle system went from a £20 million budget to over £216 million. The NHS National Programme for IT cost over £10 billion before it was scrapped. In both cases, the post-mortems pointed to the same root cause: the people building the system and the people commissioning it weren't aligned on what was actually needed.

Your project won't be on that scale. But the principle holds. A clear, honest, problem-focused brief is one of the best investments you can make before a single line of code gets written.

Kat Korson is the founder of Red Eagle Tech, a London-based software development firm specialising in bespoke solutions for UK SMEs.

‍