Photo: Google Gemini · AI-generated
A proposal is on your desk. Sixty pages, a number at the end, a date. Someone has to sign it.
Most buyers read it the way it was written to be read: from the front, with the price as the last thing they see. We read it differently, because our CTO once sat where you sit. He wrote the requirements for an SAP rollout as the client and lived with the result for years. Here is what we check, in order, before anyone signs.
1. What the proposal is quiet about
A proposal defines the work by what is in it. The risk lives in what is not. So the first pass is a list of absences: the systems the new software has to talk to, the data that has to move over from the old one, the environments it will run in, who supports it after launch.
The integration list is the sharpest test. Every system the software must read from or write to should be named, with the direction. For an IT partner of a large telecoms provider, the whole project was one dictated format: quotations had to leave Lexware as the provider’s XML. A proposal that does not name that format cannot have priced it, however long it is.
2. Whether the estimate has a shape
One number and one date for a system with six modules is a guess with a signature under it. A credible estimate has phases. It says what goes live first, what “done” means for each phase, and what the client has to provide by when.
A medical products group went live with its ERP one module at a time, sales and shipping first, purchasing and production later, with the earlier modules in production throughout. That order was in the plan before the price was. If a proposal cannot tell you what you will be using after month three, it has not been thought through to month three.
3. Who owns what the day after signing
Source code, data, documentation, the hosting account, the domain, the build pipeline. For each one: whose name is on it, and what happens if you part ways. This is rarely stated and often uncomfortable to ask. Ask anyway. A proposal that is silent here is usually silent in the supplier’s favour.
4. The assumptions, wherever they are hiding
Every proposal carries assumptions, usually in an appendix or a footnote: the client provides test data, the legacy system’s interface is documented, the vendor’s API is available, decisions come within five working days. Each assumption is a risk that has been moved onto you without a price tag. We list them, and for each one we ask what happens to the schedule and the cost if it does not hold.
5. Who actually estimated it
Was the estimate made by the people who will build it, or by someone who sells? Is the team named, and what happens when one of them leaves in month four? An estimate from a sales engineer for a team that has not met yet is a different document from one written by the developers who will be on the calls.
The three questions buyers do not ask
What it costs if it goes right. The launch price is the small number. Hosting, updates, support and the changes your business will need in year two are the large one, and they are almost never in the proposal.
What happens when reality contradicts the specification. It will. The question is whether the proposal has a mechanism for that, a change process with a cost, or whether every discovery becomes a negotiation.
Whether you can take the work elsewhere. A specification, a data model or a prototype that only the author can use is not an asset. It is a dependency.
What a second opinion is not
It is not a competing bid. When we assess someone else’s proposal, we say what we would change and whether we would sign it. If the proposal is good, the assessment says so, and that is a fine outcome. The written report is yours, vendor-neutral, and usable in a tender. What follows is a workshop, a deeper assessment, or nothing.
Five working days is usually enough. Read how our technical consulting packages are set up, or send us the proposal and talk to us about what a second pair of eyes would look at first.