How to write a software project brief that gets accurate quotes

A software project brief that gets accurate quotes is short, specific and honest. It states the problem and the outcome you need, who uses the product, the main flows, the systems it must connect to, your constraints, a budget range and a deadline. It does not try to design the solution. Two to four pages is enough, and a brief you can write in an afternoon will save weeks of back and forth.

Key takeaways

• Briefs fail mostly because they describe a solution without the problem, hide the budget, or leave out the integrations and constraints that actually decide the price.
• A useful brief answers a fixed set of questions: why, for whom, what the main flows are, what it connects to, what limits apply, how much and by when.
• Sharing a budget range does not inflate quotes; it lets agencies propose something that fits and lets you compare like with like.
• Say what is out of scope and what you are unsure about, because the unknowns are where estimates go wrong.
• Describe users and flows in plain language with a few concrete scenarios, and leave the technology choice to the people you hire unless you have a real constraint.
• Compare proposals on scope, assumptions, team, ownership, process and risk, not on the headline price alone.
• Good agencies will ask you questions back, and the quality of their questions is itself a signal.

Why do software briefs fail?

Briefs fail when they leave out the information that decides cost, or when they prescribe a solution so early that nobody can challenge it.

The same patterns repeat:

• Feature lists with no purpose. A list of 40 features tells a reader what to build but not why. They cannot judge which ones matter, so they price all of them or guess.
• No budget. Without a range, agencies quote for different products. One proposes a lean version, another a platform, and you cannot compare them.
• Hidden integrations. “It connects to our CRM” can mean an afternoon or a month, depending on the CRM. If the brief does not name it, quotes diverge.
• Hidden constraints. A legal requirement, a mandatory hosting provider or an in-house team that will take over the code changes the plan. Mentioned late, it changes the price.
• Technology first. Specifying a framework before explaining the problem limits the options and sometimes hurts the result.
• A brief for everything. Trying to cover version one, two and three at once makes the first release enormous. Quotes come back large and vague.

The fix for all of these is the same: write the facts that a stranger would need to estimate the work, and nothing else. Estimates are people times weeks, and the brief is what lets someone count both; see how much custom software development costs.

What should a project brief include?

Include the facts that change the estimate, and leave out the opinions that do not.

Include	Leave out
The problem and the outcome you want, with the metric that proves it	A long company history
Who the users are and what each needs to do	Pixel-level screen designs you are not committed to
The main flows, written as short scenarios	Every conceivable feature for the next three years
Existing systems and integrations, by name	Technology mandates without a reason
Constraints: legal, security, hosting, brand, language, accessibility	Vague adjectives like “modern”, “intuitive”, “scalable”
Budget range and deadline, with the reason for the date	Confidential data that is not needed to estimate
What is out of scope for this phase	Instructions on how the agency should organise its team
What you are unsure about	Pretending you have decided what you have not
Who decides and how fast	An exhaustive wish list without priorities

What does a brief template look like?

Copy this into a document and fill it in. Where you do not know, write “unknown”, because an honest gap is more useful than an invented answer.

# Project brief: [working name]

## 1. Summary (3-4 sentences)
What we want built, for whom, and why now.

## 2. The problem
- What is happening today (the manual process, the tool that falls short, the lost revenue)?
- Who is affected and how often?
- What have we already tried?

## 3. Outcome and success metric
- The one result this project must achieve:
- How we will measure it (number, date):
- What would make us call it a failure:

## 4. Users and roles
| Role | Who they are | Main things they need to do | Approx. number |
|---|---|---|---|
| e.g. Customer | | | |
| e.g. Staff member | | | |
| e.g. Administrator | | | |

## 5. Main flows (scenarios)
For each, write: who, what they want, steps, what happens at the end.
1. [Flow name]:
2. [Flow name]:
3. [Flow name]:
Edge cases we already know about:

## 6. Scope
- Must have in this phase:
- Nice to have if time allows:
- Explicitly out of scope:

## 7. Integrations and existing systems
| System | What it does for us | What data goes in/out | Documentation / API available? |
|---|---|---|---|
| e.g. payments, CRM, ERP, e-mail, identity | | | |

## 8. Data
- Data we already have (format, volume, quality):
- Data to migrate, if any:
- Sensitive data involved (personal, health, financial):

## 9. Platforms and devices
- Web / iOS / Android / desktop:
- Browsers or devices we must support:
- Languages and locales:

## 10. Constraints
- Legal and compliance (GDPR, sector rules):
- Security requirements (SSO, audit logs, data residency):
- Hosting or cloud requirements:
- Brand and design assets available:
- Accessibility requirements:
- Technology we must or must not use, and why:

## 11. Team and decision-making
- Who is the single point of contact?
- Who approves scope and design, and how quickly can they respond?
- Will our own developers work on this or take over the code later?

## 12. Budget and timeline
- Budget range: [< 25k / 25-75k / 75-150k / 150k+ EUR, or your own range]
- Is the budget fixed or flexible?
- Target launch date and what drives it:
- Hard deadlines (event, regulation, funding):

## 13. Risks and unknowns
- What we are least sure about:
- What has gone wrong on similar projects before:

## 14. What we need from the proposal
- Scope and assumptions
- Team (names, roles, seniority)
- Plan with milestones and demos
- Price and what is excluded
- Ownership of code, accounts and documentation
- Post-launch support and running costs
- Two questions you want us to answer

Fill the sections in order. Sections 3, 5, 7 and 12 do most of the work. If you only have an hour, write those four well.

How do you describe users and flows?

Describe users by what they need to do, and flows as short scenarios with a beginning and an end.

For users, a role table is enough. For each role, write a sentence on who they are and three to five things they must be able to do. Mention how many there are, because designing for 20 people differs from designing for 20,000. Note anything unusual, such as non-technical users or users who must be verified.

For flows, scenarios beat feature lists. Compare these two descriptions:

• Weak: “Booking system with calendar, notifications and payments.”
• Strong: “A patient opens the clinic’s page on their phone, picks a treatment, sees free slots for the next two weeks, books one, pays a deposit by card and receives an e-mail and an SMS confirmation. If they cancel more than 24 hours before, the deposit is refunded automatically.”

The second version tells a reader about screens, payment handling, notifications and a business rule. A person can estimate from it.

Write three to six core flows. Add the edge cases you already know of: what happens if payment fails, if two people book the same slot, if a user forgets their password. You do not need to solve them. Mentioning them shows where the complexity sits.

How do you describe integrations?

Name each system, say what you need from it, and say whether you have access to documentation.

For every integration write down:

1. The system and its version, for example Stripe, HubSpot, an ERP product, or a custom internal database.
2. What the software should send or receive, in plain terms.
3. How often, and whether in real time.
4. Whether an API exists and whether you can get a test environment.
5. Who on your side can grant access.

Integrations are the biggest source of surprise in quotes, because the effort depends on a system outside the project. If you do not know whether an API exists, say so. A good agency will then propose a short investigation rather than guess. Also say which integrations could be done by hand for the first weeks. That sometimes removes entire items from the first release.

How do you describe constraints?

State the constraints that change how the product is built, and explain why each exists.

Typical ones are:

• Legal and data: GDPR, handling of health or financial data, data stored in a specific region.
• Security: single sign-on, audit logs, penetration testing before launch.
• Hosting: a mandatory cloud provider or an on-premises requirement.
• People: your in-house team will maintain the code, so the stack must match their skills.
• Brand and design: an existing design system or none at all.
• Accessibility: a stated standard such as WCAG.
• Languages: the number of locales at launch.

If a constraint is a preference rather than a rule, say so. A constraint with a reason can sometimes be met in a cheaper way; one without a reason just shrinks the options.

How should you describe budget and deadline?

Give a range and the reason for your date. Both help.

A budget range does not make quotes rise to fill it. It lets an agency decide what to propose: a focused product that fits comfortably or an honest “this does not fit your budget, here is what does”. Without it you receive proposals for different products and have to guess the difference. If you want orientation, the budget bands used on many studio contact forms are under €25k, €25k to €75k, €75k to €150k and €150k and above. Roughly, the lower bands buy a narrow, focused product; the higher bands pay for more roles, integrations, compliance and platforms. For more on this, see how much an MVP costs.

Say whether the budget is fixed or flexible. If it is fixed, say what you would cut first.

For the deadline, give the date and the reason. “We need to launch before a trade show on 14 March” is a real constraint. “As soon as possible” is not. If the date is firm, you should expect the proposal to cut scope to meet it. A realistic plan for the calendar is covered in how long an MVP takes.

How do you compare the proposals you get back?

Compare them on the same dimensions, not on the total at the bottom. A table helps. Score each proposal against the rows below.

What to compare	What to look for	Warning signs
Understanding	They restate your problem accurately and ask good questions	Generic text that could be about any project
Scope	A clear list of what is included, what is excluded and why	One number, no breakdown
Assumptions	Written assumptions about integrations, users and data	No assumptions, or “everything is included”
Team	Named people, roles, seniority, who writes the code	“A dedicated team” with no names; senior sales, junior delivery
Process	Discovery, regular demos, a live URL early, code review, tests	Months without anything to see
Plan	Milestones with dates and demos	A single end date
Price model	Fixed, time and materials or monthly, with how changes are handled	A fixed price with an undefined scope
Ownership	You own the repository, cloud accounts, domain and documentation from day one	The agency holds the keys
Quality	Automated tests, monitoring, security review, accessibility	No mention of testing or monitoring
After launch	Running costs, support options, handover	Silence about hosting and maintenance
Risk	The risks they see in your project, named	“No risks”

A useful trick is to ask each agency to list the three things most likely to make the project late or expensive. Their answer shows whether they have understood your problem. Weight those answers heavily.

Look for the proposal that understood the problem, is clear about trade-offs and gives you the most control. For a broader guide to picking a partner, see how to choose a software development company.

What questions should you ask agencies?

Ask questions whose answers cannot be faked with a sales pitch.

1. Who will write the code, and will they be on the calls?
2. Can I speak to someone who has built something like this, and see something running?
3. What is your process from kickoff to launch, and when will I first see working software?
4. How do you handle changes in scope, and what happens to the price and the date?
5. Who owns the repository, cloud accounts, domain and documentation, and from when?
6. What is not included in this price?
7. How do you test, and what happens before a release reaches users?
8. How do you monitor the product after launch, and who is on call?
9. What will the monthly running costs be at my expected usage?
10. What would you cut to fit my budget, and what would you refuse to cut?
11. What could make this project fail, from your experience?
12. If we part ways in six months, what do I take with me and how easily can another team continue?
13. If the product uses AI or language models: how will you evaluate quality and what will each answer cost?

For anything involving a language model, see AI in your business: from demo to production. A direct “we would not do that, because…” is a better sign than agreement with everything you say.

How Hidook approaches this

Hidook is a remote-first product engineering studio. When a brief arrives, a senior engineer, not a sales representative, replies, usually within one working day. We do not price a project from a single message. We start with a discovery in week 0: workshops, constraints and the one metric that matters, ending with a written scope and a price.

We read a brief looking for what is missing, and we will tell you if a spreadsheet or an off-the-shelf tool would solve the problem. If you have not written a brief, we can work from a conversation, and the template above is a good place to start either way. For how we work after that, see MVP development and web app and SaaS development.

Frequently asked questions

How long should a project brief be?

Two to four pages is enough for most projects. A longer brief is only useful if the extra length is concrete information such as integration details or a data description. A short brief that answers the key questions beats a long one full of general statements.

Should I include my budget in the brief?

Yes, as a range. It lets agencies propose something that fits and makes the proposals comparable. If you are unsure, use a band such as under €25k, €25k to €75k, €75k to €150k or €150k and above. Revealing a range rarely raises quotes, and hiding it often wastes time on proposals you cannot afford.

What if I do not know what I need technically?

Describe the problem, the users and the flows, and leave the technology to the agency. Say what you do not know. A good partner will suggest options and explain the trade-offs. Technical decisions can be a part of discovery rather than something you must settle beforehand.

How many agencies should I send the brief to?

Three to five is usually enough. Fewer limits your comparison and more creates work for you without improving the decision. Send the same brief to all of them and answer their questions in the same way.

Can an agency help me write the brief?

Yes. A discovery phase is partly a paid or free version of this exercise: workshops that turn a rough idea into a written scope. If you cannot write the brief yourself, ask for discovery instead of asking for a fixed quote straight away.

What should I do if the quotes differ wildly?

Differences usually come from different assumptions about scope, team seniority or what is included. Ask each agency to list their assumptions and exclusions, and compare those rather than the totals. Often the cheapest and the dearest are pricing different products.

If you have a draft brief, or only the first page of one, write to no.bs@hidook.tech or book a call at https://hidook.tech/contact/.