The cheaper proposal usually costs more by year two because the cost has not disappeared. It has moved into your own team, a thin support model, a long list of exclusions or a renewal price that only appears later. Compare proposals on the same scope over three years, including your internal effort and exit terms, before anyone compares price.
Two proposals land on the table. One is 30% cheaper. The scope sections look similar, both vendors have the right logos on their slides, and the cheaper one comes with a confident delivery team. Finance likes it. The decision feels easy.
I have sat on both sides of that table. I have written the proposal that won on price, and I have inherited the contract that came with it. Most of the time the cheaper proposal is not cheaper. The cost has moved somewhere you are not looking yet.
Where does the money go in a cheaper proposal?
Cost in a technology deal behaves like water. Squeeze it out of one place and it shows up in another. When a proposal is much lower than the rest, I start by asking where the difference went. It is usually one of four places.
Into your team. The proposal assumes your people will do things the other vendor priced in. Testing, data clean-up, user access, change approvals, coordination with your other suppliers. None of it is written as a cost to you. It appears later as overtime, delays and a project manager who never gets a quiet week.
Into the support model. The build is priced well. The run is thin. Support hours are capped, response times are measured in business days, and anything outside the standard catalogue is a change request. Year one feels fine because the project team is still around. Year two is when you find out what you bought.
Into the exclusions. Every proposal has a list of things it does not cover. In the cheaper one, that list is longer and more interesting. Licensing, migration of historical data, integration with one awkward legacy system, security hardening, documentation. Read the exclusions before you read the price.
Into the renewal. Introductory pricing, a discount that only applies to the first term, or cloud credits that run out after twelve months. The commercial model is built to win the deal, and the margin comes back at renewal when switching is expensive.
How do you compare two proposals fairly?
The fix is not complicated, but it needs discipline. Before anyone compares price, put both proposals on the same footing.
- Same scope. Write one list of everything you need delivered and operated. For each proposal, mark what is included, what is excluded and what is vague. Vague counts as excluded until it is in writing.
- Three years, not the first invoice. Build a simple three-year view: build cost, run cost, licences, support, expected change requests and the renewal price. Ask each vendor for the renewal terms now, while you can still negotiate.
- Your own cost. Estimate the internal effort each proposal assumes. Hours from your team are not free just because they do not appear on an invoice.
- Exit terms. What happens if it goes wrong? Notice periods, data handover, transition support, termination fees. A proposal that is cheap to enter and expensive to leave is not cheap.
Once the proposals are normalised, the gap often shrinks to almost nothing. Sometimes it reverses. Occasionally the cheaper proposal is still cheaper, and then you can choose it with confidence instead of hope.
What should you ask a vendor before signing?
- What is excluded here that the other proposal included?
- Who is actually delivering, and have they done this at our scale?
- What does it cost over three years, not on the first invoice?
- Who inherits the support work this proposal does not mention?
- What happens at renewal, at a change request and at exit?
- What does a failure cost compared with the saving?
If nobody in the room can answer these, the decision is not ready.
The real comparison
A proposal is a promise about the future, priced in the present. The cheaper one is often cheaper because it promises less, or because it moves the cost to a place that will not show up in this year’s budget.
The vendor may be perfectly honest. The comparison is simply incomplete, and the job is to complete it before you sign, while every option is still open and the conversation is still friendly.
I prefer practical answers to impressive ones. In vendor selection, the practical answer is usually a spreadsheet with three years in it and a short list of awkward questions.
Two related notes: discounts that only last a year behave the same way, as I explain in cloud credits are not a strategy, and the signed agreement matters as much as the price, which is the subject of the contract is the architecture document nobody reads.