How to brief a software development agency (and get proposals you can compare)

Key points

• Describe the problem and the people who have it, not a list of screens.
• Name the one job the first version must do, and sort everything else into must-haves and nice-to-haves.
• State deadlines as the business events behind them, and describe your budget approach in words.
• Ask for assumptions, risks, the named team, how change is handled and ownership terms in every proposal.
• Send every agency the same brief, then compare the proposals on the same headings.
• A team that asks no questions about your brief has not understood it yet.

Why the brief decides the proposals you get

An agency can only estimate what it understands. Give three teams a vague idea and you get three proposals for three different products, with nothing to compare but the bottom line. Give them the same clear brief and the differences that remain are real: in approach, in team, in judgment.

A brief is not a specification. You do not need every screen designed or every rule decided; working that out is part of what you are hiring for. The GOV.UK Service Manual puts the order plainly: before you commit to building, understand the problem that needs to be solved. The brief is where you share what you already know about that problem, so the first call is spent on the gaps.

What to send before the first call

• The problem and who has it. Describe the people, what they are trying to get done, and how they manage today. A workaround in a spreadsheet tells an agency more than a feature list does; Jobs to be done is a useful way to frame it.
• What success looks like. The change you expect to see once it works: a task that takes less effort, customers who come back, a process that no longer needs a person to re-key data. Say how you would notice it.
• The one job the first version must do. If the product did only one thing well, what would it be? This keeps a first version small; How to build an MVP covers why that matters.
• Users and roles. Who signs in, and what each kind of user can see and do: customers, staff, administrators, partners.
• Must-haves and nice-to-haves. Sort features into what the product cannot work without and what would improve it. The GOV.UK Service Manual describes this as MoSCoW: must have, should have, could have and will not have. The last group, written down, prevents more arguments than any other.
• Existing systems, data and integrations. What it has to connect to, where the data lives now, how much of it there is, and who controls each system. Name the tools you already pay for.
• Design assets. A brand, a logo, existing screens, sketches, or products you admire and why. Say if there is nothing yet; that is fine, and it changes the proposal.
• Constraints. Deadlines stated as the business events behind them, such as an investor meeting, a launch event or a contract that starts with a customer, so the team can suggest what to cut. Your budget approach in words, such as a set budget for the first version that you want the most value within, or an amount you can sustain over a longer build. Any compliance or data rules that apply to your sector or your customers.
• Who decides. The person who will answer questions, approve the scope and accept the work. If decisions need a co-founder, a board or a client, say so.

Finish the brief by saying what you want back. Without that, every agency answers a different question.

• The assumptions behind any estimate, written down.
• The risks they see, and what they would do first to reduce them.
• The team: who would do the work, by role and, ideally, by name.
• How they handle change, and which engagement model they propose; Dedicated team vs fixed scope explains the options.
• How you will see progress, and what you can try yourself along the way.
• Ownership terms: whose account the code and services live in, and when the intellectual property is assigned to you. Who owns the code covers what to look for.

A one-page brief template

Copy these headings and answer each in a few plain sentences. Leave a heading in with "not decided yet" rather than deleting it; that is useful information.

1. Product name and a one-line description of what it does.
2. The problem: who has it, and how they deal with it today.
3. What success looks like, and how you would notice it.
4. The one job the first version must do.
5. Users and roles: each kind of user and what they can do.
6. Must-haves, nice-to-haves, and what is out of scope for now.
7. Existing systems, data and integrations, and who controls each.
8. Design assets you have, or a note that there are none.
9. Constraints: the business events behind any deadline, your budget approach in words, and any compliance rules.
10. Who decides, and who answers questions day to day.
11. What you want back: assumptions, risks, team, how change is handled, how you will see progress, and ownership terms.

What to leave out

• A technology choice, unless it is a real constraint, such as a system your team already runs. Let the agencies propose one and explain why; the explanation is part of what you are comparing.
• A long specification. Detail you have not tested with users tends to fix the wrong things in place. A fuller document can follow once you have chosen a team; How to write a PRD covers it.
• Secrets. Do not put passwords, customer data or access keys in a brief. If something truly sensitive is needed to understand the project, share it later, under an agreement, with the team you choose.

Comparing proposals like for like

Put the proposals side by side under the same headings before you look at the totals. A lower number often means a smaller product, a riskier plan or a different set of assumptions, not a cheaper version of the same thing.

1. Check each proposal against your must-haves and mark anything missing or added.
2. List the assumptions from every proposal in one place, and ask each agency about the ones the others made.
3. Ask the cheapest and the most expensive to explain the difference; the answer usually shows what each one has understood.
4. Meet the people who would do the work, not only the people who sold it.

The Agile Manifesto values customer collaboration over contract negotiation. How an agency handles your questions at this stage is the best preview you will get of how it will handle them later. More questions to ask are in How to choose a software development company.

Red flags

• No questions. A proposal that arrives without a single question about your brief was written from a template.
• An estimate without assumptions. A number with nothing behind it cannot be checked, and every surprise later becomes your problem.
• Unclear ownership. Vague answers about whose account the code lives in, or when the intellectual property becomes yours.
• Everything is a must-have. A team that agrees to build every feature in the first version is not helping you choose.
• A low bid with a heavy change process. Martin Fowler warns that some firms bid low on an agreed scope and plan to make their profit on change requests.
• No named people. If you cannot learn who would build your product, you cannot judge them.

After you send it

Use the first call to test understanding in both directions: let the agency play your problem back to you, and ask it to explain anything in the proposal you do not follow. Expect the scope to sharpen after a scoping stage; a good team will tell you which of your must-haves it would challenge, and why.

At BYD Tech the founders are on every call, there is a ballpark on the intro call and a written estimate after scoping, and the code lives in the client’s GitHub from day one. MVP development explains how a first version starts.