Procurement, IT, and finance leaders · 11 min read
Most software deals are lost before the contract is signed - not on price, but on scope. The vendor's pre-sales team has run your evaluation hundreds of times and knows exactly which costs to leave out of the proposal. You run it once. This guide is the buyer-side framework to close that gap: how to evaluate a software vendor so the price you're quoted is close to the price you actually pay.
It applies whether you're a 24-person team buying a $40K tool or a Fortune 500 running a $40M programme - the principles are the same; only the depth changes.
Published 14 June 2026
Download the guide(PDF)The single highest-leverage move in any evaluation is to author your own scope first. When the vendor writes the scope, every ambiguity is resolved in their favour and becomes a future change order. When you write it, you set the requirements, the acceptance criteria, and the explicit exclusions.
A strong buyer-authored scope lists what must be delivered with testable acceptance criteria ("the integration syncs X records in under Y minutes with zero data loss"), names the exclusions you've seen vendors slip (data cleansing, environment setup, training depth), and defines the red lines you'll walk away over.
Vendor lock-in is invisible at signing and only surfaces when you try to leave. Proprietary data formats, custom integrations, retrained staff, and egress fees all raise your exit cost. The defence is to make lock-in a number, not a feeling: project the switching cost at years 3, 5, and 7 and put it on the table during negotiation.
Ask explicitly: in what format is my data returned on exit, at what cost, and on what timeline? If the answer is vague, that's the lock-in.
What a vendor shows in a demo and what they commit to in the contract are two different documents. Demoware - features shown but never contractually committed - is one of the most common post-signature surprises. Keep a running list of every capability, SLA, and timeline claimed in the sales process, then check each one against the proposal. Anything demonstrated but not written down is a question, not a commitment.
Confirm where your data lives, how it's encrypted, who can access it, and what happens to it on exit. For regulated buyers, require the vendor to map their controls to your obligations (SOC 2, ISO 27001, HIPAA, GDPR) - not just claim certification. For AI vendors, this is its own discipline; see the AI-vendor guide.
The references a vendor provides are pre-screened to say good things. The signal is in the ones they don't offer: customers of a similar size, in a similar industry, who went live recently. Ask specifically about the gap between the sales promise and the implementation reality, and about anything that became a change order.
Lock your evaluation model - weighted criteria tied to your scope - before proposals arrive, so a slick presentation can't move the goalposts. Then score how much of your scope each proposal actually covers. Proposals that look cheaper usually cover less; a coverage score makes that visible and comparable.
Authoring your own scope before the vendor does. It is the single highest-leverage move: when you define the requirements, acceptance criteria, and exclusions, ambiguity is resolved in your favour instead of becoming a change order later.
Ask for written dollar estimates - before signing - for the line items routinely excluded from fixed-fee proposals: data migration and cleansing, integrations, non-production environments, training depth, post-go-live hypercare, and renewal uplifts.
Make it a number. Project the switching cost at years 3, 5, and 7, and require the vendor to state the format, cost, and timeline for returning your data on exit. Vague answers are the lock-in.
Related guides
From principle to practice
Benchside generates the scope, the interrogation questions, and the lock-in math for your specific vendor - your first project is free.