How to read a software proposal

You send the same brief to three firms and get back three numbers that differ by 40%. There's no obvious way to compare them, because each proposal describes the work slightly differently and none of them show their reasoning. The instinct is to take the middle one. The better move is to work out what each one is actually assuming, because that's where the difference lives.

Look for the assumptions section first

A proposal without a written assumptions list is a proposal where the assumptions are still going to exist, just undisclosed. Who provides the designs, how many rounds of revision are included, what the data migration looks like, whether third-party API access is your problem or theirs, what happens if a dependency you control arrives late.

A cheap quote with no assumptions section and an expensive one with two pages of them are frequently the same project. The second firm has just done the thinking in advance and priced it.

Check what the number covers

• Is QA and bug fixing inside the estimate or billed separately afterwards?
• Does it include deployment, environment setup, and the first production release?
• Is project management in the rate or a percentage on top?
• Who pays for third-party licences, hosting, and API usage during the build?
• Is there a warranty period after launch, and how long?
• What happens to the estimate if scope changes, and who decides that it has?

Six lines of questions will usually explain most of a 40% gap. In our experience the remaining difference is genuine, and it's about seniority of the people who'll actually be assigned.

Estimates that vary suspiciously little

A breakdown where every line item is a neat multiple of five days is a breakdown that was written backwards from a target price. Real estimates are lumpy, because real work is: authentication is well understood and predictable, a migration from a legacy schema nobody documented is not.

The most trustworthy proposals we've seen say plainly that a particular area is uncertain and propose a short paid discovery to price it properly, rather than putting a confident-looking number on something nobody can know yet.

What happens when it goes wrong

Every proposal describes the successful case. The useful questions are about the other one. What's the process when a deadline is going to be missed, and how early do you find out? What's the exit if the relationship isn't working at month three? Who owns the code and the infrastructure if you stop working together tomorrow?

The answer to that last one should be 'you do', without qualification. If a proposal is vague about IP ownership or hosting access, that's the single most important thing to resolve before signature, and it's much harder to resolve after.

The reference call is worth the hour

Ask for a client whose project went less smoothly than planned, not just the showcase one. How a firm behaves during a difficult month tells you far more than a case study, and a firm that can point to one and describe honestly what they changed is usually the one to work with.

“Compare what's excluded, not what's quoted. The excluded work doesn't disappear; it just arrives later as a change request.”

Before you sign

1. 1Get every proposal restated against the same written assumptions
2. 2Confirm what's in the number: QA, PM, deployment, warranty, licences
3. 3Ask for the named people and their actual allocation
4. 4Establish in writing that you own the code, data, and infrastructure
5. 5Agree how scope changes are raised, priced, and approved
6. 6Take one reference call about a project that got difficult

None of this guarantees a good outcome. It does mean the number you agreed at the start bears some relationship to the number at the end, which is most of what people actually want from a proposal.