A second opinion on a software quote: what to check before you sign

Two quotes for the same project differ threefold and both are defensible. Not because one supplier is lying — because each counted something different, and neither wrote down what.

Comparing software quotes is an unfair task: you are judging something that does not exist yet, from a document written by a salesperson. It can still be done better than by reading the last page.

What quotes leave out most often

• What is not included. The most important sentence in a quote. Without a scope boundary every addition is extra work, and every piece of extra work is a conversation about money mid-project.
• Who owns the result. Source code, data, the domain, server access. Easy to settle before signing and very hard to settle at a parting.
• What happens after launch. Are bug fixes included? For how long? Is the difference between a bug and a change written down anywhere?
• What is needed from you. Projects do not stall on code, they stall on inputs and approvals. A quote that does not name your part assumes an ideal world.
• Running costs. Development is a one-off; operating it is forever. A missing monthly figure tends to arrive as a surprise after launch.

Fixed price versus time and materials

Neither is better. A fixed price moves risk onto the supplier, who prices it in — and when the brief shifts mid-project, which it always does, a negotiation follows. Time and materials is cheaper for the same scope, but you have no ceiling.

So the question is not which model to pick, but: how will I learn the project is drifting, early enough to do something about it? The answer is a working version handed over as you go, not a monthly report of percentages complete.

Five questions that reveal more than a price list

• What part of this will I see working within a month?
• How do I get at the source code during the project rather than at the end?
• Who will actually do the work, and what have they done before?
• What happens if we find halfway through that part of the brief was wrong?
• What will this cost me monthly once it is running?

The answers matter more than the number. A supplier who answers the fourth with "that will not happen" has either not done many projects or is not telling the truth.

When the best answer is not to buy

Some of the briefs that reach us do not need new software. They need a tool the company already pays for to be set up properly, or a process that gets worked around to be changed. We say so — losing one job is cheaper than a client who works out a year later that they paid for nothing.

It runs the other way too: sometimes building your own is cheaper than continuing to pay for a system that does not fit. Telling those two situations apart takes a few hours of conversation, not a month of analysis.

What we do

We read the brief and the proposal on your desk and say what is missing, what is inflated and where the risk hides in the detail. We also do an architecture review of an existing solution, with a sequence of steps ordered by impact, and a comparison of technologies against your constraints — including what each choice closes off later.

None of it is conditional on us doing the work that follows. If you want a view before deciding, get in touch — the first consultation carries no obligation, and there is more about this area on our services page.