A good brief explains the business problem, the people who will use the software, the workflows it must support, the systems it must connect to and your constraints: deadline, budget range and who will own it afterwards. It describes outcomes, not screens. One or two pages is usually enough to get accurate, comparable quotes.
Why most quotes are wildly different
Send the same one-line request, "we need an app for our sales team", to five agencies and you will get five numbers that differ by a factor of ten. That isn't because some are dishonest. Each one is silently filling the gaps in your request with its own assumptions about scope, quality and risk.
A clear brief removes those assumptions. Quotes become comparable, the conversation starts at the right level, and you learn quickly which partners actually understood the problem.
What to include in a software brief
- The business problem. What is slow, expensive, error-prone or impossible today? Put a number on it if you can: hours lost per week, orders mistyped per month.
- The goal. What will be different six months after launch? Describe outcomes ("dispatch confirms orders the same day"), not features.
- Who will use it. List each type of user (customers, sales staff, warehouse, managers, admins) roughly how many, and on which devices.
- Key workflows. Walk through the three to five most important journeys step by step, in plain language.
- Existing systems. Name every tool the software must read from or write to: accounting, CRM, payment gateway, WhatsApp, spreadsheets.
- Data. What data exists today, where it lives and roughly how much of it needs migrating.
- Constraints. Fixed deadlines, compliance requirements, hosting preferences, languages and accessibility needs.
- Budget range. Even a broad range helps a partner propose the right approach instead of guessing.
- Ownership after launch. Who will run, maintain and pay for the system once it is live?
What to leave out
- Detailed screen designs. Unless you already have a design system, let the partner propose the interface after understanding the workflows.
- Technology mandates without a reason. "Must be React" is fine if your team maintains React; otherwise describe the outcome and ask for a recommendation.
- Every feature you can think of. Mark features as must have, should have and later. A focused first release ships faster and teaches you what really matters.
A one-page template
| Section | Answer in one or two sentences |
|---|---|
| Problem | What hurts today, and what does it cost? |
| Goal | What will be true six months after launch? |
| Users | Who uses it, how many, on what devices? |
| Top workflows | The three to five journeys that matter most. |
| Integrations | Systems it must connect to. |
| Data | What exists, where, and how much to migrate. |
| Constraints | Deadlines, compliance, hosting, languages. |
| Budget | A range you are comfortable with. |
| After launch | Who owns, runs and maintains it? |
How to compare the quotes you get back
- Did they ask questions? A partner who quotes without asking anything is quoting their assumptions, not your project.
- Is the first release clearly defined? Look for a written scope with milestones, not an hourly estimate with no end.
- Who owns the code? You should own the source code, the repository and the cloud accounts.
- What happens after launch? Maintenance, monitoring and support should be explained, not an afterthought.
- Who will actually build it? Ask to meet the people writing the code, not just the salesperson.
We follow exactly this approach in a short discovery phase before quoting a fixed scope. See how we work on custom software development.