How to evaluate a software development proposal

You asked three firms for a proposal on the same project. One came back at a quarter of the price of another, all three sound confident, and none of them has told you anything that lets you compare them. This is the normal outcome, and it is not mainly about dishonesty. A proposal is written before anyone understands the work, so the spread between them is mostly a measure of how differently they each guessed.

What follows is what we actually read for when we see somebody else's proposal, and the parts of it that are checkable rather than a matter of taste. The useful signals are structural, which means you can find them without being technical.

What the price is not telling you

A low number can mean four different things, and they are not equally bad. It can mean a smaller scope was understood. It can mean cheaper people. It can mean the firm is buying the logo and will make it back on changes. Or it can mean genuine efficiency, because they have built something close to this before.

Only the first of those is visible from the proposal itself, and it is visible only if the scope is written precisely enough to compare. Which is why everything below is about the scope section rather than the commercial one. If you cannot tell what each firm thinks it is building, the prices are not comparable numbers, they are three different projects.

The four things a scope has to name

A scope that cannot say what is excluded is not a scope. Read each proposal for these four, and mark which it answers:

• Who the users are, by role. Not "staff". Which roles, and what each one can see and do.
• What is explicitly out. The absence of an exclusions list is the single most reliable warning sign in a proposal.
• What happens to the data that already exists. Migration is where fixed prices die, and it is almost always under-specified.
• What done means for each deliverable. Covered below, because it is the one most often missing entirely.

If a proposal answers all four, you can negotiate it. If it answers none, there is nothing to negotiate yet, and the right response is to ask for a scoping exercise rather than a cheaper quote. The method for that is in how to scope a software project before anyone writes code.

Acceptance criteria are the real test

This is the part worth borrowing from people who buy software at scale and publish their methods. The UK government's Service Manual page on writing user stories defines acceptance criteria as a list of outcomes used as a checklist to confirm that the service has done its job, and notes they are often written as a list beginning with "it's done when".

That phrase is the test. Take any line item in the proposal in front of you and try to finish the sentence "this is done when...". If you cannot, neither can the supplier, and neither will the person who has to sign the invoice in month four. Disputes at the end of software projects are almost never about quality in the abstract. They are about two parties holding different unwritten definitions of finished.

The same page carries a second idea that transfers directly. It says that if you are struggling to write the goal of a story, you should reconsider why you think you need that feature. Applied to a proposal, a line item whose purpose nobody can state in one sentence is a line item to cut before you sign, not after.

It also advises splitting anything too large into pieces completable within a single iteration. A proposal with five deliverables each described in a paragraph is less finished than one with thirty described in a line, even though the first looks tidier.

What a missing discovery actually means

If a firm quotes a fixed price and a fixed timeline on the basis of one meeting, that is the finding, not the convenience. The same Service Manual is explicit about the sequence on its page on how the discovery phase works: before you commit to building a service, you need to understand the problem that needs to be solved, and you should not start building during discovery.

It also gives a duration, which is the useful part for calibrating what you are being offered. There is no set time period for a discovery, it says, but around four to eight weeks is typical, longer for problems nobody has researched and less for familiar ones. Set that against a supplier who has priced your whole build after a ninety minute call.

The page lists what that phase is for: reframing any pre-defined solution back into a problem, identifying constraints such as legislation, contracts and legacy technology, and quantifying the cost of the problem. Notice that a proposal cannot contain any of those if nobody did the work. And the page says something a commercial supplier will rarely tell you: it is not a failure to stop at the end of discovery if the research shows that is the best thing to do.

So the strongest signal available is a firm that will sell you the scoping work separately and tell you the answer might be do not build this. We have written about the version of that we practise in how to choose a software development company, where checking whether they scope before they quote is one of the seven questions.

Reading the estimate

Estimates given in round months are a tell worth naming. Real estimates are uneven, because the work is uneven. A plan reading four weeks, three weeks, six weeks has been thought about. A plan reading three months, three months, three months has been divided.

The clauses worth finding before you sign

• Who owns the code, in writing. Assume nothing from the sales conversation. We covered the ways this goes wrong in who owns the source code when you hire a developer.
• Where the repository lives from day one. In your organisation's account, with your access, from the first commit rather than at handover.
• What the change process costs. Not whether changes are allowed, but the named rate and who approves them.
• What happens if you stop. What you keep, in a usable state, if the project is cancelled in month three.
• Who the named people are. A proposal that will not name who does the work is a proposal from a firm that does not know yet.

None of these are adversarial requests. A supplier who has done this before will have answers ready, and the speed of the answer tells you as much as its content.

The honest limits

A good proposal does not predict a good project. It predicts a firm that writes carefully, which correlates with delivery but does not guarantee it. The reverse is also true: a weak document can come from a strong team who are simply bad at proposals, and the fix there is a conversation rather than elimination.

The government guidance above comes from public sector digital delivery, where budgets, timescales and procurement rules differ substantially from a thirty person company buying an internal system. We cite it because its definitions are published and testable, not because your project should be run like a government programme.

We are also a supplier, so read this as interested. The specific cost to us of writing it down: the four-part scope test and the acceptance criteria test are the two things most likely to make a prospect ask us for a smaller first phase than we proposed, and smaller first phases are harder to staff. We still think they are the right thing to buy.

And a limit on comparison itself. Three proposals priced four times apart often cannot be reconciled on paper at all, because they describe different projects. The resolution is not a spreadsheet. It is to go back to all three with the same written scope and ask them to reprice it, which costs you a week and is the cheapest week in the project. The seller's side of that same document, which is useful to read precisely because it shows what is being optimised for, is set out by BDG Labs in what makes a B2B proposal that wins.