In this article (12 sections)
Asking three vendors for a quote and getting numbers that run from USD 6,000 to USD 40,000 doesn't mean two of them are robbing you. Almost always it means each one understood a different project, because what you sent them allowed for three different projects.
A well-built request isn't paperwork. It's what makes the quotes comparable, and along the way it's what makes the project deliverable.
What doesn't work
A loose list of features. "Login, customer management, reports, mobile app." Every item allows ten different readings of how big it is.
A forty-page document written by someone who doesn't do the work. Long isn't precise.
A description of the system you want. Sounds odd, but describing the solution before the problem is what gets you paying for something that wasn't necessary. You know your operation; the vendor knows the ways to solve it.
What does work, in seven parts
1. The problem, in one paragraph
What hurts today, in business terms. Not "we need a management system", but "three people spend Monday morning consolidating spreadsheets and the numbers still don't match".
This orients everything else, and sometimes it produces the best possible surprise: an honest vendor telling you your problem is solved by something much cheaper.
2. How it works today
The actual loop, step by step, from an order coming in to getting paid. Who does each step, what document comes out of it, where it jams.
Write it with the people who do the work, not with the person who supervises it. The two versions come out different and the first one is the good one.
3. The exceptions
This is the part that decides the most money and the part that almost never gets written down.
The customer who gets invoiced differently. The discount only the owner can approve. The product sold by weight and stocked by unit. The branch that runs on a different process.
Exceptions are 40% of the work in a build. A quote that doesn't account for them is a quote that's going to grow, and the argument about whether they were included is going to be unpleasant for everyone.
4. Who uses it and what each one sees
The list of roles and, for each one, what they can see and what they can do. Permissions are one of those things that grow without anyone noticing.
5. What it has to talk to
The systems it has to integrate with, and what each one offers: a documented API, an accessible database, or nothing. It's the single fact that moves the number most, and the one the vendor can't find out on their own.
6. The volumes
How many concurrent users, how many records today, how much it grows per year, how many transactions a day. And the peaks: if month end multiplies it by ten, say so.
7. What's NOT in scope
An explicit list of what stays out of this stage. It's counterintuitive and it's the most useful section in the document: it stops each vendor from quoting a different scope just in case.
What to ask them to send back
So you can actually compare, ask everyone to answer in the same structure:
- The scope as they understood it, in their own words. If it doesn't match what you meant, you find out now instead of in month two.
- An itemized price: build, migration, training, infrastructure, first-year maintenance.
- A timeline with intermediate deliveries, not a single final date.
- What they need from you and when: decisions, data, access, people to test it.
- What's explicitly out of scope.
- The contracting model and what happens when scope changes.
- Ownership of the code and the accounts.
Put that last point in writing from the request onward. It's far easier to agree on before there's a commercial relationship than after.
A shortcut that works very well
If writing all of this sounds like a lot —and for plenty of companies it is— there's a better path than sending something incomplete: pay for a short discovery stage.
A vendor spends a week or two understanding your operation and produces the scope document, with screens, rules and acceptance criteria. It usually costs between 5% and 10% of the project.
Here's the important part: that document is yours, and it works for getting quotes from three other vendors on exactly the same basis. Agree to it that way from the start.
Signs the quote you got is no good
- A round number with no breakdown.
- It doesn't mention any of your exceptions, which means they either didn't read them or didn't account for them.
- It doesn't say what they need from you. Every project needs things from the client; the one who doesn't list them will come asking late.
- It matches your budget suspiciously well instead of matching your scope.
- It's much cheaper than the other two with no explanation of why. Sometimes that's real efficiency; sometimes it's that they understood less and you'll find out later.