How to brief a software project (and get accurate quotes)

The short answer

A good software project brief describes the problem you're solving, who will use the tool, what it needs to do (and, just as importantly, what it doesn't need to do yet), any systems it needs to connect to, your rough budget and timeline, and how you'll know it's worked. You don't need technical language or a finished specification. The clearer you are about the problem and the people using it, the more accurate and comparable the quotes you get back will be.

Why a weak brief leads to a bad quote

Developers quote against what they're told. A brief that just says "we need an app for our business" forces every quote to guess at scope, and guesses vary wildly, which is why two quotes for what sounds like "the same project" can be miles apart. A clear brief removes the guessing, so the quotes you get back are actually comparing the same thing, and the final price is far less likely to move once work begins.

What to include in a brief

1. The problem, not the solution

Start with what's actually going wrong today, not what you've decided the fix should be. "We're tracking jobs across five spreadsheets and nobody has the full picture" tells a developer far more than "we need a dashboard", because it leaves room for them to suggest the right solution rather than just building what you asked for literally.

2. Who will use it

Name the actual users: your staff, your customers, both. Mention roughly how many, and whether they're comfortable with technology or need something very simple. A tool for five staff who use it daily has different design needs to a portal for hundreds of occasional customers.

3. What it needs to do

List the core things the tool must do, separate from things that would be nice eventually. Being honest about what's essential versus what's a future wish list is one of the biggest factors in keeping cost and timeline realistic. Our guide on off-the-shelf vs custom software is worth reading before this step, since a surprising number of "custom software" needs turn out to be solved by an existing tool instead.

4. What it connects to

Mention any systems it needs to talk to: your CRM, your accounting software, your website, a booking calendar. Integration work is often the part that adds unexpected cost if it's discovered partway through rather than planned for from the start.

5. Your rough budget and timeline

Developers aren't offended by a budget range, and it helps enormously. "Somewhere between £5,000 and £10,000" lets a developer suggest a version that fits, rather than scoping something far outside what you can spend and finding out after the quote arrives. If you genuinely don't know, say that too, along with what you're comparing against, like a rough idea from a similar project you've heard about.

6. How you'll know it's worked

A line on what success looks like, like "staff stop using spreadsheets for job tracking within a month" or "customers can check their booking status without calling us", helps a developer understand what actually matters, which sometimes differs from the feature list itself.

A simple brief template

Problem: What's going wrong today, in plain terms.
Users: Who will use it, roughly how many, how comfortable they are with technology.
Must-haves: The things it absolutely needs to do.
Nice-to-haves: Things that would help but aren't essential yet.
Connects to: Other systems it needs to work with.
Budget: A rough range, or "not sure yet".
Timeline: When you'd ideally like it live, and why if there's a real deadline.
Success looks like: What changes day to day if this works.

This fits on one page for most small business projects. Longer, more technical specifications matter more for larger builds, but for a first brief, clarity beats length every time.

Questions a developer should be asking you back

If a developer quotes a fixed price from your brief without asking any follow-up questions, that's often a sign they haven't actually understood the scope, rather than a sign the brief was perfect. Expect to be asked things like:

• What happens currently when this problem occurs, step by step?
• Who needs to approve or sign off the final result?
• Are there busy periods or deadlines the build needs to work around?
• What's the plan if usage grows significantly in future?

A back-and-forth before the quote is a good sign, not a red flag. It usually means the eventual number will hold.

What this means for cost and timeline

Scope is the single biggest factor in the cost of custom software, far more than which developer you choose. Our guide on how much a custom app costs for a small business breaks down the typical ranges once scope is clear. As a rough starting point, idea shaping and a clickable prototype start from around £750, an internal tool or dashboard from around £3,000, and a customer portal or booking system considerably more, depending on complexity; see pricing for the full range.

If you've got an idea but nothing written down yet, our solution for having an app idea but no one to build it is a good starting point, and our example of an idea becoming a clickable prototype shows what that early stage typically looks like in practice, well before a full brief is needed.

If you'd rather not do this yourself

We'll help you turn a rough idea into a brief that gets accurate quotes, and often the brief itself reveals that part of what you need already exists off the shelf. Have a look at our custom apps and tools service, or tell us about your idea and we'll help shape it on a free call.