How do you compare two software vendor proposals?

Not by reading one after the other. Two proposals written to two different briefs describe two different projects, and reading them in sequence compares writing quality. The only comparison that means anything is one where both documents have been made to answer the same list of questions — including the questions neither of them raised.

Do it in three steps. Normalise: put both proposals into one table of the same rows. Mark the silences: an unanswered row is a value, not a blank. Then compare, with price near the bottom rather than the top — you already know which is cheaper, and the reason it is cheaper is almost always in the rows above it.

Two quotes for the same platform, 41,000 and 62,000. Normalised into one table, the cheaper one had no back-office scope, no named infrastructure owner, no exit terms and no recurring cost estimate. The expensive one was not expensive. It was the only one of the two that had been asked to describe the whole job.

Write your own question list first

Before you open either document. If the list comes from one of the proposals, it will favour that proposal, and you will not notice.

Score coverage before content

For each row: answered, partly answered, or absent. Do this before judging whether any answer is good. Two vendors answering differently is a decision; one vendor not answering is a risk.

Put the silences in the table, not in a footnote

A blank row is the single most valuable output of the exercise. It is simultaneously the difference in price, your question list, and the thing you will otherwise discover in month four.

Compare the ownership rows against each other

Source, repository, infrastructure, IP assignment, exit. Five rows where a difference between vendors changes the value of the deal more than any price difference on the page.

Total three years, not the build

Build price plus recurring costs plus support plus third-party fees, over a realistic horizon. Proposals compete on the first number; you live with the total.

Normalise the timelines too

One vendor quoting to a demo and another quoting to production readiness are not offering the same date. Decide what "finished" means, then re-read both timelines against it.

Send the gaps back and compare the replies

How a vendor answers a list of gaps is itself comparable evidence — often better evidence than the original documents, because both are finally answering the same thing.

State your criteria before you decide

Write down what would make you choose one, in advance. A comparison without stated criteria reliably concludes in favour of whichever proposal was read last.

• A comparison can rank documents. It cannot rank companies. References, delivery history and the actual people assigned are outside anything on the page.
• Normalisation can flatten a genuinely better approach into an identical-looking row. Where a difference is architectural, read it properly rather than scoring it.
• Nothing here produces a "best vendor" verdict, and you should distrust anything that does without stating its criteria and its uncertainty.
• Comparing more than three proposals rarely improves the decision and reliably delays it.