In this article
The accuracy of a software estimate depends more on the brief than on the estimator. A vague brief produces a wide range, padding, or a confident number that changes later. A good brief lets a development company give you a figure they can stand behind, and it also makes the proposals you receive comparable with each other. After reading many briefs, and producing estimates from them, we know what makes the difference, and it is less than most people expect.
Describe the problem before the solution
Start with what the software is for: who uses it, what they do today, and what should be different afterwards. A brief that opens with "we need a React Native app with a dashboard" tells us what you have already decided. A brief that opens with "our inspectors fill in paper checklists that take two days to reach the office" tells us what the software must achieve, and lets us question decisions that might be wrong. Both are useful, and the second one is the one most briefs leave out.
List the users and what each one needs to do
For each kind of user, write down the handful of things they must be able to do. "A driver can see today's jobs, navigate to each one, record proof of delivery and report a problem." This is more useful than a feature list because it says why each feature exists and lets the estimator see the whole flow. If there are several kinds of user, this section also reveals how much of the product each role shares.
Say what exists already
Existing systems the software must connect to, with the integration method if you know it. Existing data that must be migrated, with rough volumes. Existing designs, brand guidelines or an application being replaced. Integrations and migrations are where estimates most often go wrong, so naming them up front, even without detail, improves accuracy more than anything else in the brief.
State the constraints
Platforms, including whether iOS, Android, web or all three are required and in what order. Compliance requirements such as healthcare or financial regulation. Languages and regions. Offline use. Accessibility requirements. A launch date that is fixed by something external, such as an event or a contract. Each of these changes the plan, and leaving them out means the estimate assumes the simplest case.
Give a budget range, or explain why not
Many clients withhold the budget, expecting a lower price. It usually produces proposals that are either far above the budget, wasting everyone's time, or far below it because the estimator assumed a smaller scope. A range, even a wide one, lets a development company propose a version of the product that fits it and say what would be left for a later phase. If you cannot share a budget, share the business value instead: what the software will save or earn, which gives the same signal.
Separate must-have from later
Mark each capability as needed for the first release or acceptable later. A first version that does five things well and ships in four months is usually worth more than a complete product that ships in twelve, and an estimator who knows what can wait can propose a staged plan with a smaller first number.
Include what you have, however rough
Sketches, screenshots of the current process, a spreadsheet that the software will replace, a competitor you admire with notes on what you would change. These communicate more in five minutes than pages of text, and nobody expects them to be polished.
What you can leave out
Technology choices, unless they are constraints. Detailed screen-by-screen specifications, which belong in discovery rather than in a brief. Legal boilerplate, which belongs in the contract. And a long company history. The brief is for the estimator, and a page or two with the sections above is enough for a useful first estimate.
What a good response looks like
A proposal worth reading repeats your problem in its own words, so you can check it was understood. It proposes a team and a timeline rather than only a price. It names the assumptions behind the number and the questions that would change it. And it suggests a staged plan where one is sensible. A proposal that offers a precise price with no assumptions and no questions has guessed, and the guess will be corrected later at your expense.
If you would like a template for the sections above, or want us to scope a brief you already have, our requirements engineering page describes how we run discovery, and estimates are free.