How to write a brief vendors can quote on

A brief vendors can quote on states the problem, the users, the must-have features, the constraints and how you will judge success, in two to five pages. When every vendor gets the same brief, the quotes become comparable, and the differences between them tell you something real about each vendor.

Why does the brief matter so much?

A vague brief gets vague quotes. If you say "we need an app for our customers," each vendor fills the gaps differently. One assumes an iPhone app, one a web portal, one a full platform with admin screens. Their prices differ by a lot, and you cannot tell why.

A clear brief does three things. It lets vendors quote the same thing. It shows you which vendors ask good questions. And it forces you to decide what you want, which is the hardest part.

What should a brief contain?

Use these sections in this order.

1. Context: who you are, what the business does, and why this project exists now. Three or four sentences.
2. The problem or opportunity: what is not working today, or what do you want to make possible? Write it as a business problem, not a solution. "Customers call to check delivery status and we lose two staff hours a day" tells a vendor more than "we need a tracking page."
3. The users: who will use it, whether customers, staff, partners or admins? How many, roughly? What devices do they use? What languages? For Indian businesses, say whether you need Hindi, Marathi or other languages, and whether users are mostly on mobile.
4. What it must do: split the list into must-have, should-have and nice-to-have. This is the most valuable part of the brief. A short list of must-haves keeps the first version affordable.
5. Existing systems and integrations: what it must connect to, such as your accounting software, CRM, payment gateway, WhatsApp, an ERP. Name them and say what data moves between them.
6. Constraints: deadline and the reason for it, budget range, technology preferences or restrictions, hosting location, compliance needs. If the system will hold personal data, say so, because the Digital Personal Data Protection Act, 2023 affects design (see the first steps under DPDP).
7. Ownership and exit: state your expectations, for example that you own the code, designs, accounts and data; the vendor hands over documentation; hosting accounts sit in your name.
8. What success looks like: how will you know it worked? Fewer support calls, more orders, faster onboarding, a launch by a certain date. Measures make decisions easier later.
9. How you will choose: the criteria and the timetable, including when quotes are due, when you will decide, who is involved.

What should vendors send back?

Tell them what you want in the reply, so the quotes line up:

• An approach in plain language and the main technology choices with reasons.
• A breakdown by phase or milestone, with what is delivered at each.
• Assumptions and exclusions.
• Timeline with dates or durations.
• Costs: build, hosting, licences, maintenance after launch.
• Team: who will work on it and who you will deal with.
• Two relevant examples of past work, with a reference you can call.
• Payment schedule tied to milestones.

Ask for questions in writing and share the answers with all vendors. It keeps the process fair.

What mistakes ruin a brief?

1. Describing the solution instead of the problem: you may rule out better options.
2. Listing every feature as a must-have: the quote swells, and nothing is prioritised.
3. Hiding the budget: vendors then guess high or low.
4. Leaving out the people who will use it: staff who run the daily process know the real requirements.
5. Skipping what happens after launch: hosting, fixes and updates are part of the cost of ownership.
6. Sending different information to different vendors: you cannot compare the results.
7. No decision date: quotes drift, and so does the project.

How do you handle uncertainty?

Often you do not know enough to write a firm brief. That is normal. If the idea is new, the right first step is a short discovery phase that produces a clearer scope, a prototype and a plan, then a build quote based on it. Our Product Discovery Sprint does this for new products. For ongoing uncertainty, a phased contract with a review after each phase limits your risk.

How do you read the replies?

Look beyond the number. Which vendor asked sharp questions about your business? Whose approach fits your constraints? Whose assumptions are clearest? Whose team will you actually meet? If a quote lands far from the others, ask why before dismissing it. An outside reviewer can help you here; see how to get a second opinion on a tech quote.

What are the trade-offs?

Writing a good brief takes a day or two. That feels slow when you want to move fast. It is quicker than a rebuild caused by a misunderstanding.

A very detailed brief can also lock in your assumptions. Leave room for vendors to propose better options, and ask them to explain any departure from the brief.

If the project is small, a shorter version is fine: problem, users, must-haves, constraints, deadline. The template scales down.

Where does TechSum fit?

We help businesses write requirements and RFPs, select vendors and manage them through delivery. That is part of Tech Consultancy. If you already have quotes, a Tech Second Opinion gives you an independent read. For technical leadership on an ongoing basis, see the fractional CTO page. You can also run the free health check if the project is a website rebuild.