The third quote arrives and looks nothing like the other two. One says 8 weeks, another says 5 months, and the last one asks for "a discovery meeting" before giving any number at all. You go back to what you sent the three vendors: a four-line email saying "we need a system to manage our customers' orders, with an app and reports". Each vendor pictured a different system and priced the one they pictured.
In software design and development, the quality of a quote depends almost entirely on the quality of the requirements the client hands over. A serious vendor can't guess how many users you'll have, which ERP the system has to talk to, or what "reports" means to your management team. If they don't know, they assume, and every assumption turns into a wider price range or a scope change halfway through the project.
This guide is for the client side: what to put in a software requirements brief before you ask for a price, with a template you can copy. If you want to know how the project is organized once it starts, we cover that in the stages and deliverables of software design and development. And if your question is how much it might cost, see what drives the cost of a custom application.
Why a good brief lowers the price (or at least the risk)
A vendor quoting a poorly defined project has two options. They can pad the estimate to protect themselves, or they can quote low and make it back later through change orders. Neither works in your favor.
Clear requirements won't guarantee a cheap project. What they do is make quotes comparable. If three vendors read the same document and one comes in at three times the price, you now have a concrete conversation: what did that vendor see that the others missed?
You don't need an 80-page formal specification. ISO/IEC/IEEE 29148:2018, the international reference on requirements engineering, defines what makes a good requirement. In short: each one should state a need precisely, without ambiguity, and in a way that can be verified. With that in mind, a 4 to 8 page document is usually enough for a first round of quotes.
What a software requirements brief should include
These are the blocks that, in our experience, move an estimate the most. Order them however you like, but make sure they're all there.
The problem, not the solution
Start with what hurts today and what it costs. "Sales reps lose two hours a day building quotes in Excel and 15% go out with outdated prices" tells a vendor far more than "we want a sales portal". If you describe the solution before the problem, you narrow the options: sometimes the right answer is an integration or a Power Platform app, not a full system.
Also say what success looks like. One or two metrics are enough: customer response time, billing errors, hours spent on data entry.
Users and volume
Who will use the system? Field sales, warehouse staff, external customers, managers who only look at reports. For each group, note how many people there are, which device they work from and whether they need to work offline. An app for 12 supervisors is a different project from a portal for 4,000 customers.
Processes the system must cover
Describe the real workflow, exceptions included. What happens when an order arrives incomplete? Who approves a discount above a certain amount? Exceptions are what eat development hours, and they almost never show up in the first email.
Integrations and data
List the systems it has to talk to (ERP, CRM, electronic invoicing, Microsoft 365, legacy AS/400 systems) and, if you know, how: API, flat files, direct database access. If you don't know, say so. "We're not sure whether the ERP has an API" is useful information for whoever is quoting.
Also include what data the system will handle and where it comes from. If data needs to be migrated, give a rough volume and describe what shape it's in.
Personal data
If the system will process Chilean national ID numbers (RUT), addresses, health data or employee data, say so upfront. Chile's Law 21,719 requires data protection by design (article 14 quáter) and, when a vendor processes data on your company's behalf, a contract that sets out the purpose, duration, scope, types of data and categories of data subjects (article 15 bis). The law is currently set to take effect on December 1, 2026; on October 28 the Senate passed a bill that would move that date to October 15, 2027, but it is still before the Chamber of Deputies. Whatever the final date, the system you're quoting now will run under this law, so the vendor should account for it from the design stage.
Constraints
Available budget (even a range), deadline and the reason for it, required or banned technologies, where it must be hosted (for example, in your Azure subscription) and who will maintain it afterwards. Many companies leave out the budget range for fear the vendor will "use all of it". In practice the opposite happens: without a range, you get proposals for a project you can't afford.
Acceptance criteria: how you'll say "this is done"
A requirement you can't verify ends in an argument. "The system must be fast" doesn't help. "Searching for a customer by tax ID returns results in under 2 seconds with 50 concurrent users" does.
For the most important features, write the criterion using the Given / When / Then structure from the Gherkin format used in testing: an initial context, an action and an observable expected result.
Given a sales rep has a customer with overdue debt
When they try to enter a new order for that customer
Then the system blocks the order and shows the amount owed
You don't need one for every screen. Five to ten scenarios covering the critical processes are enough for the vendor to understand your business rules, and they give you something to check deliveries against.
Requirements template for requesting a quote
Copy this list and fill it in. Where you don't have an answer, write "to be defined" instead of leaving it blank, so the vendor knows to ask.
- Context: what the company does and which area is requesting the system.
- Current problem and its cost (hours, errors, lost sales).
- Objective and how success will be measured.
- Users: types, numbers, devices, offline use.
- Processes to cover, with their exceptions.
- Features sorted into "must have", "nice to have" and "later".
- Integrations: system, direction of data flow and known mechanism.
- Data: what data, source, volume to migrate, personal data involved.
- Non-functional requirements: availability, response times, security, accessibility.
- Acceptance criteria for critical processes.
- Constraints: budget (range), deadline and reason, technology, hosting.
- Ongoing operation: who provides support and who administers the system.
- Contact person and who makes decisions in your company.
Item 6 helps the most with pricing. If the budget doesn't cover everything, a prioritized list lets the vendor propose a first version with the must-haves instead of walking away from the project.
Common mistakes when asking for a quote
| Mistake | What it causes | How to avoid it |
|---|---|---|
| Describing the solution ("we want an app") | Proposals that miss the real problem | Start with the problem and its cost |
| Leaving out integrations | Expensive scope changes mid-project | List every system, even if you don't know how it connects |
| Sending each vendor a different document | Quotes you can't compare | One document, same answers for everyone |
| Asking for a fixed price on an open scope | Estimates padded for risk | Paid discovery phase or a narrower scope |
| Hiding the budget | Proposals out of range | Share a reference range |
On the fourth point: when a project still has a lot of open questions, the sensible move is usually to pay for a short discovery phase with a concrete deliverable, then get development quoted with that information. It costs a bit upfront and saves you the overrun of a badly estimated fixed price.
Frequently asked questions
How long should a software requirements brief be to get a quote?
For a first quote, 4 to 8 pages is usually enough if it covers the problem, users, processes, integrations, constraints and acceptance criteria. Longer isn't better if it's still ambiguous.
Do I need technical knowledge to write it?
No. The brief describes the business: what happens today, what should happen and how you'll check it. Choosing the technology is the vendor's job, unless your company has constraints (for example, using Azure or Microsoft 365).
What if I can't define everything before getting a quote?
Mark the open items as "to be defined" and ask for a short discovery phase. A good vendor will tell you what information is missing and how the estimate changes depending on each assumption.
Next step
If you already have a draft brief, or just the problem and a few notes, we can review it with you and help turn it into a scope that can be quoted. At Disrupsoft we start every project by understanding your requirements and processes before designing the solution. Take a look at our custom software development service and let's talk.
