How to Write a Software Project Brief That Gets Accurate Quotes

Suppliers price uncertainty. When a brief is vague, each supplier fills the gaps with their own assumptions. One assumes a simple admin panel, another assumes full role-based permissions. The quotes then differ widely, and you cannot tell which is realistic.

A clear brief narrows those assumptions. You get quotes that are closer together, easier to compare and less likely to grow later through change requests.

Use this outline as your template. Each section can be a few short paragraphs or a list. A useful brief is often only a few pages long.

1. Start with the problem, not the solution. Write two or three sentences on what is going wrong. For example: "Orders are re-keyed from email into our stock system, which causes errors and delays." This lets suppliers suggest better approaches.
2. Define success in measurable terms. Use your own measures, such as "staff no longer re-key orders" or "customers can book without phoning". Avoid technical goals here.
3. List the users and what each needs to do. Write simple user stories: "As a warehouse manager, I want to see today's orders so that I can plan picking." Name every role, including admins.
4. Split features into must-have, nice-to-have and out of scope. This is the single most useful step for accurate quotes. It also lets suppliers quote phase one and phase two separately.
5. Describe every integration precisely. Name the system and what data moves in which direction. "Push paid orders from Shopify to Xero as invoices" is far better than "connect to accounting".
6. State data and volume facts. Number of users, records, orders per day, files to migrate. Scale affects architecture and cost.
7. Note constraints. Existing hosting, preferred technologies, compliance needs such as GDPR, accessibility targets such as WCAG 2.2 AA, and any security requirements.
8. Add examples. Screenshots of tools you like, sketches, spreadsheets you use today or sample documents. Examples remove more ambiguity than paragraphs.
9. Give a budget range and timeline. A range helps suppliers propose the right level of solution rather than guessing. Explain which dates are fixed and why.
10. Explain how you will choose. Say what matters most: price, speed, experience, support or a mix. Ask for quotes in a consistent format.

Detailed enough that two people would build roughly the same thing. For each must-have feature, cover:

• Who uses it.
• What they do, step by step, in a sentence or two.
• What rules apply, such as approvals, limits or notifications.
• What happens when something goes wrong, such as a failed payment.

You do not need database designs or technical specifications. A good supplier will produce those during discovery.

An example of a well-described feature

Compare "customers can book appointments" with this version: "Customers choose a service, see available slots for the next four weeks and book one. They get a confirmation email and a reminder the day before. Staff can block out holidays. Customers can cancel up to a set time before the appointment; after that they must phone." The second version is longer, but every supplier will now quote the same thing. It also exposes questions early, such as whether payment is taken at booking and whether staff need a calendar sync.

Yes, as a range. Many businesses hold it back in the hope of a lower quote. In practice, it leads to proposals that are either over-engineered or too basic. A range lets each supplier tell you what is realistic for that money and what they would leave for later.

If you genuinely do not know, say so and ask suppliers to quote the must-haves and nice-to-haves as separate line items.

• Naming a technology without a reason. Ask for a specific stack only if you have a real constraint, such as an in-house team.
• "Like Uber, but for…" descriptions. These hide large amounts of scope. Describe the actual features you need.
• Forgetting the admin side. Reports, user management and content editing are often a large share of the work.
• Ignoring content and data migration. Moving old data and writing new content take real time.
• No out-of-scope list. Without it, suppliers include different extras.
• Sending different information to different suppliers. Share answers to questions with everyone.

Put each proposal into a simple comparison sheet. Look beyond the total figure.

1. Check which must-haves each supplier has included and which they have assumed away.
2. Read the assumptions and exclusions sections carefully.
3. Compare how testing, project management and deployment are covered.
4. Look at the proposed timeline and team.
5. Check post-launch support terms and code ownership.
6. Ask each shortlisted supplier to walk you through their estimate.

A quote that is much lower than the rest usually means something has been left out or misunderstood.

Some projects, especially new products, cannot be fully specified up front. In that case, ask for a paid discovery phase. The supplier works with you for a short period to define users, features, architecture and a costed plan. You then have a much stronger brief, whether or not you continue with the same supplier.

For new products, our guide to planning a SaaS MVP explains how to decide what to build first.

We are happy to review a draft brief and point out gaps before you send it out. If you are planning a new system, our web application development team can also run a short discovery phase, or support the wider plan through digital transformation consulting. Send us your brief when you are ready.