We've received hundreds of project briefs over the years. Some led to productive first calls and signed projects within weeks. Others led to three meetings where nobody was sure what we were actually building.
The difference is almost never about the size of the project or the budget. It's about the brief.
A good brief saves everyone time — yours and ours. A bad brief creates a cycle of misaligned expectations, vague estimates, and wasted meetings. And the worst part: most bad briefs aren't written by people who don't know what they want. They're written by people who know exactly what they want but describe it in a way that's impossible to scope.
This post is the guide we wish we could send to every prospect before the first call. We've also turned it into a fillable Word template you can download and send to any agency — including us.
What a brief is actually for
A brief isn't a contract. It's not a spec document. It's not a 40-page PDF with wireframes and database schemas.
A brief is a conversation starter. Its job is to give the agency enough context to have an intelligent first meeting — one where we ask the right questions instead of spending an hour figuring out the basics.
The best briefs are short, clear, and honest about what's known and what's not.
The 7 things your brief should answer
You don't need a template. You don't need headers and formatting. You just need to answer these seven questions clearly. A page or two is enough.
1. What problem are you solving?
Not "what do you want to build" — what problem exists today? "Our sales team tracks leads in spreadsheets and loses 30% of follow-ups" is useful. "We need a CRM" is not — because the solution might not be a CRM at all.
Start with the pain. The solution comes later.
2. Who will use this software?
List the actual people. "Our 12-person operations team" is clear. "Various stakeholders across the organization" is not. How technical are they? How often will they use it? Are they internal employees or external clients?
The user profile shapes every design and technical decision.
3. What exists today?
What are people using right now to handle this problem? Spreadsheets? A competitor's tool? Paper? Nothing? If there's an existing system, what works about it and what doesn't?
This tells the agency whether they're replacing something, improving something, or building from zero — three very different projects.
4. What does success look like?
Not features — outcomes. "Our order processing time drops from 3 days to 4 hours." "We stop losing client data between departments." "We can onboard a new team member without a week of training."
If you can't describe success without listing features, you might be solution-shopping instead of problem-solving.
5. What's your budget range?
This is the question everyone avoids, and it's the one that matters most.
You don't need an exact number. But "somewhere between $20K and $50K" is infinitely more useful than "we'll discuss budget later." Here's why: a $20K solution and a $200K solution for the same problem look completely different. Without a range, the agency either guesses wrong or gives you a proposal that doesn't match your reality.
Being upfront about budget isn't a negotiation disadvantage. It's a time saver. A good agency will tell you what's possible within your range — and what's not.
6. What's your timeline?
Is there a hard deadline — a regulatory requirement, a product launch, a contract start date? Or is the timeline flexible? Both are fine, but an agency needs to know which one it is before scoping.
"We need this live by September" and "we'd like to start when the right partner is available" lead to very different project plans.
7. What have you already decided — and what's open?
Have you already chosen a platform? Do you need it to work with specific tools? Is the design done? Are there technical constraints from your IT team?
And equally important: what are you not sure about? Where do you want the agency's input? The best projects are the ones where the client is honest about what they don't know.
What to leave out
A brief is not a spec. Resist the urge to include:
Screen-by-screen wireframes you drew yourself. These lock the conversation into a specific solution before the problem is fully understood. Share them as reference if you want, but don't treat them as requirements.
Detailed technical requirements you researched online. "Must use microservices architecture" or "must be built in React" — unless you have a technical team that made this decision, leave the tech to the agency. That's what you're hiring them for.
A 30-page document. If your brief is longer than 3 pages, it's not a brief anymore. It's a spec that the agency will need to validate anyway.
What makes us take a brief seriously
After years of reading project briefs, here are the signals that tell us this prospect has thought it through:
They describe the problem before the solution. They're honest about what they don't know. They include a budget range without being asked. They've explained who the users are and what they're using today. And the brief is concise — because clarity takes effort, and a concise brief signals a client who respects everyone's time.
On the other hand, briefs that say "we need an app" with no context, briefs that are 40 pages of copied requirements from another project, and briefs with no budget and no timeline — these usually lead to long sales cycles and mismatched expectations.
Download the template
We've turned these 7 questions into a one-page template you can fill in and send to any agency — including us. It's a simple Word document with guided prompts for each section. No email required, no signup.
Download the Software Brief Template (Word) →
Use this as a checklist
Before you send your next brief to any agency — not just us — run through the seven questions above. If you can answer all seven in plain language, your first meeting will be productive, your estimate will be more accurate, and the project will start on stronger footing.
We've written about how we deliver projects once work begins and how we evaluate build-vs-buy decisions. But all of that starts with a clear brief. The project's quality ceiling is set before the first line of code.
Have a project in mind and want to talk it through? Start the conversation →