Send the same project to five suppliers and you can receive five prices that differ several times over. That is rarely because some are dishonest. It is because the brief left gaps, and each supplier filled them differently.

Why quotes vary so much

A quote is a price for a set of assumptions. If the brief does not say how many users there will be, whether there is an existing system to connect to, or what happens after launch, each supplier assumes something.

The cheapest quote is often the one that assumed the least. The way to get comparable prices is to remove the guessing.

What to include

  • The problem, and who has it today.
  • Who will use the software, and roughly how many of them.
  • What it must do, separated from what would be nice.
  • The systems it has to connect to.
  • The constraints: deadline, budget range, and any regulations that apply.
  • What success looks like, in a form that can be checked.
  • Who on your side will make decisions.

None of this requires technical knowledge. It requires knowing your own business, which you do better than any supplier.

What to leave out

You do not need to design the screens or choose the technology. Detailed designs in a brief tend to fix the solution before anyone has examined the problem, and a supplier may see a simpler way.

Name a technology only when there is a real reason, such as a system you already run or a team that will maintain the result.

Share your budget

Many buyers keep the budget secret, expecting a lower price. The usual result is the opposite of helpful: suppliers guess, and you receive proposals for three different sizes of project.

A range tells suppliers what kind of answer to give. A good one will tell you what fits inside it and what does not, which is the information you need.

Comparing the replies

  • Read the assumptions first, the price second.
  • Check what is included: testing, deployment, documentation, support after launch.
  • Ask who owns the code.
  • Notice who asked you questions before quoting.

A supplier who asked good questions has understood the work. One who quoted without asking has priced their own guess.

A short template

  • Background: who we are and what prompted this.
  • The problem: what is going wrong, and for whom.
  • Requirements: must have, should have, could have.
  • Constraints: time, budget range, existing systems.
  • Success: how we will know it worked.
  • Process: who decides, and when we will choose.

Two pages under these headings will get you better quotes than twenty pages of specification.

Our service

Custom Software Development