A brief is useful when you have one. It is not a requirement for starting a good conversation about software.
You may know the problem, the users or the outcome you want without knowing the full system yet. That is enough to begin.
The useful question is not "Have we written the perfect brief?" It is "What do we already understand, and what still needs to be worked out?"
In most cases, it's not that one vendor is ripping you off. It's that your brief left too much room for interpretation. Vendors filled in the gaps differently, and those gaps are expensive.
What to Bring to the First Conversation
1. Business context, not just features
Don't just list what you want built. Explain why you need it. What problem are you solving? What does success look like? What happens if you don't build this?
This context helps vendors understand priorities and suggest alternatives you might not have considered.
2. User clarity
Who uses this system? How many users? What are they trying to accomplish? A system for 10 internal users is fundamentally different from one serving 10,000 customers.
3. Scope boundaries
What's definitely in scope? What's definitely out? What are you unsure about? Being explicit about boundaries prevents scope creep and ensures quotes compare the same thing.
4. Constraints
Share your budget range. It tells suppliers what kind of solution to propose, so the response can match the level of scope, quality and complexity you actually need.
Also share timeline requirements and any integration constraints (existing systems, required tools, compliance needs).
5. Decision process
Who makes the final decision? What's the evaluation timeline? What criteria matter most? This helps vendors tailor their response and set appropriate expectations.
What Usually Needs Clarifying
Feature lists with no prioritization. When everything is equally important, vendors quote for everything. Identify your must-haves versus nice-to-haves.
No budget indication. Without a range, estimates tend to be cautious and hard to compare. Give a range, even a wide one. Give a range. It's okay if it's wide.
Comparing yourself to enterprise software. "Something like Salesforce but for our industry" is a million-dollar statement. Be specific about which features you actually need.
Skipping the 'why' entirely. Feature lists without context force vendors to assume the worst-case complexity. Explain the problem, and they might find a simpler solution.
A Brief You Can Build As You Go
Here's a template you can use:
Company & Context: Who you are, what industry, what size, what you're trying to accomplish.
The Problem: What's not working today. What it's costing you (time, money, opportunity).
Users: Who will use this, how many, how often.
Core Requirements: The 3-5 things it absolutely must do.
Nice-to-Haves: Features you'd want if budget allows.
Out of Scope: Things you explicitly don't need right now.
Constraints: Budget range, timeline, integrations, compliance.
Success Criteria: How you'll know this project succeeded.
How We Work From There
When you send us a clear brief, we respond with questions and observations. We want to understand the work before discussing what should happen next.
We confirm scope in writing. You'll see exactly what's included and what's not before you see a number.
Pricing is agreed with the scope and assumptions in view. The right format depends on the work, but it should be clear what you are committing to and what remains outside it.
Use the template if it helps. Otherwise, start with what you have in mind and we will help you work out what needs to be understood next.
Tagged
Written by
EverEdge Team