If you send three vendors a two-line description of your project, you will get three estimates that are hard to compare. One will have assumed a simple version, another a complete one, and the third will have padded the number to cover what they could not guess.
A good brief fixes that. It does not need to be long or technical. It needs to tell a vendor what you are trying to achieve, who will use the software and what matters most. This guide explains what to include and what to leave open, and it ends with a checklist you can copy.
Start with the problem, not the features
The most useful thing in any brief is a clear statement of why the project exists. What problem are you solving, and for whom? What will be different when it is done?
For example: “Our sales team manages quotes in spreadsheets. Quotes take two days to prepare and pricing errors are common. We want a web tool that produces quotes from our product catalogue in minutes.”
That paragraph tells a vendor far more than a list of screens. It lets them suggest simpler ways to reach the same goal, and it gives everyone a test for every later decision: does this help solve the problem?
Add how you will judge success: fewer support calls, faster onboarding or a product you can show investors by a certain date. Measurable goals are best, but an honest description is better than nothing.
Describe the users
List the types of people who will use the software and what each needs to do. Keep it simple:
- Customers browse products, place orders and track deliveries
- Warehouse staff see new orders and mark them as shipped
- Admins manage products, prices and user accounts
Include rough numbers where you know them. Ten internal users and fifty thousand public users lead to very different technical decisions. Mention the devices they use, whether they need the software on mobile, and any accessibility requirements.
Separate must-haves from nice-to-haves
This is where most briefs go wrong. Everything is listed at the same level, so vendors either estimate all of it or guess which parts you really mean.
Sort your features into three groups:
- Must-have: the product does not work without it
- Should-have: important, but the first release could ship without it
- Nice-to-have: ideas for later
Be strict with the first group. If you are building a new product, our post on what to build first in an MVP goes into this in more detail. A short must-have list gets you tighter estimates and an earlier launch, and you can still ask vendors to price the other groups separately.
List integrations and existing systems
Integrations are one of the most common sources of estimate surprises. Write down every system the new software needs to talk to:
- Payment providers, accounting software, CRMs or ERPs
- Login systems such as Microsoft or Google sign-in
- Existing databases or APIs your company already runs
- Third-party data feeds or services
For each one, note whether it has a documented API, who controls it, and whether you have test access. If you are replacing an existing system, say so and describe what data needs to move across. Data migration is often underestimated. If you are still deciding what to do with the old system, our post on whether to rewrite or refactor legacy software may help.
State your constraints
Constraints narrow the options, which makes estimates more accurate. Include anything that is fixed:
- Deadlines and the reason for them, such as a trade show, a contract renewal or a funding round
- Technology your team already uses or must support
- Hosting, for example a particular cloud provider or a requirement to keep data in a certain region
- Compliance obligations such as GDPR, accessibility standards or industry regulation
- Who maintains it after launch: the vendor, your in-house team or both
If something is a preference rather than a hard requirement, say that too.
Share a budget range
Many buyers hold back their budget in the hope of getting a lower quote. In practice, this usually makes estimates worse. Without a range, a vendor cannot tell whether you want a lean first version or a fully featured product, and they have to guess.
A range does not commit you to spending it. It lets vendors propose a scope that fits, tell you honestly if the goal is not achievable for that amount, and suggest what to cut. It also tells you quickly which vendors are a realistic fit.
How a vendor prices the work matters as well. Our guide to fixed price vs time and materials explains how each model handles risk.
Know what to leave open
A brief is not a full specification. Some things are better left for the vendor to propose:
- The technical architecture and choice of frameworks, unless you have a reason to fix them
- Detailed screen layouts, which are better worked out in design
- The exact sequence of delivery
Leaving these open lets you compare how vendors think, which is often more revealing than the price. Do invite them to ask questions. The questions a vendor asks about your brief tell you a lot about how carefully they have read it.
A brief template you can copy
Use this as a starting point. A page or two is usually enough.
- Background: your company, and the problem this project solves
- Goals: what success looks like, and how you will measure it
- Users: each type of user, what they need to do, and rough numbers
- Must-haves: the features needed for the first release
- Should-haves and nice-to-haves: to be priced separately
- Integrations: every system involved, with API and access details
- Existing systems and data: anything being replaced or migrated
- Constraints: deadlines, technology, hosting, compliance
- Budget range: and your preferred pricing model, if you have one
- After launch: who will run and maintain the software
- Open questions: anything you are unsure about and want advice on
- Contact and timeline: who decides, and when you want to choose a vendor
Send us your brief
At Dotqode, we sign an NDA before any detailed discussion, so you can share your plans openly. For an end-to-end project, we use your brief as the starting point for discovery, then break the scope into features and estimate each one. If your brief is still rough, that is fine. Contact us and we will help you fill the gaps.
