The quality of a software quote is directly proportional to the quality of the brief it's based on. A vague brief produces a vague quote - and a vague quote almost always ends in a dispute about scope. We've seen this pattern often enough that we now invest time helping clients write better briefs before we quote, because it saves everyone significant pain later.
This post is that process, written down. If you're approaching a developer or consultancy for the first time, these are the questions you need to answer before the conversation begins.
Start With the Problem, Not the Solution
The most common brief mistake is describing the software you want rather than the problem you're trying to solve. "I need a web application with a dashboard, user accounts, and a reporting module" tells a developer what to build. "I need my operations team to be able to monitor 200 client accounts in real time without building a manual report every morning" tells them what problem to solve - and gives them the context to design the right solution.
Start your brief with a plain-English description of the problem. Who has it? How often does it occur? What does it cost them in time, money, or risk? What does the current workaround look like? This context is what allows a good developer to challenge your assumptions and suggest a better approach if one exists.
Define Your Users
Who will use this software? Be specific. "Internal staff" is not a user definition. "Ten operations executives who are comfortable with spreadsheets but not with complex software, accessing the system on desktop browsers" is. User definitions matter because they determine the complexity of the interface, the level of error tolerance required, the training implications, and the support burden.
If there are multiple user types with different permissions or workflows - for example, administrators, standard users, and read-only viewers - document each one separately. This is one of the most common sources of scope creep in software projects: user roles and permissions that weren't defined upfront and get added incrementally throughout development.
Every undocumented user role discovered mid-project adds scope. Define your user types before you start, even if the definitions evolve.
Describe the Core Workflows
Walk through the key things users will actually do in the software. Not every feature, but the critical paths. If someone is using your application to onboard a new client, what are the steps? What information do they enter? What happens next? What does the end state look like? These workflow descriptions are the most useful input a developer can receive, and they're often more valuable than a list of features.
For each workflow, also describe any business rules or validation requirements. If a particular field must be unique, if a certain action requires approval, if a calculation has specific rounding requirements - these details have significant development implications and are almost impossible to estimate for without them.
Integration Requirements
Does your software need to connect to anything that already exists? Accounting systems, CRMs, payment processors, data feeds, authentication providers, email platforms? Integration work is often the highest-risk and most time-consuming part of a software project, and it's frequently underestimated because it's not visible in the user interface.
For each integration, document what data needs to flow in which direction, how frequently, and what happens when the integration fails. If you have API documentation for the systems you need to connect to, include it. If you don't know whether the system has an API, that's worth finding out before you start.
Non-Functional Requirements
These are the requirements that don't appear in a feature list but have a significant impact on architecture and cost. How many users will be using the system simultaneously? What's the acceptable response time for key operations? What are your data retention requirements? Are there regulatory compliance obligations? Does the system need to be available 24/7 or is business-hours availability acceptable?
A system designed for 10 internal users has very different architecture requirements from one designed for 10,000 external customers. A system that must be available 99.9% of the time requires very different infrastructure from one where a few hours of maintenance downtime per month is acceptable. These requirements don't need to be precise, but a reasonable range is much better than silence.
Budget and Timeline
Be honest about your budget. Developers aren't going to charge you more because you disclosed it - they're going to tell you what they can build within it, which is far more useful than a quote you can't afford to act on. If you genuinely don't know what something should cost, say so - a good developer will give you a range based on your requirements and work with you to prioritise within it.
Similarly, be honest about your timeline. If you have a hard deadline - a regulatory change, a product launch, a contract commitment - say so upfront. That constraint shapes how the project is scoped and staffed. Discovering it halfway through a project is significantly more disruptive than knowing about it at the start.
