Jump to

Skill · Vendor evaluation

Vendor evaluation.

Pick the right tool, negotiate fair terms, avoid the lock-in traps.

Pick the right tool or service, negotiate fair terms, and avoid the lock-in traps. A structured evaluation runs five phases: define the need, decide build versus buy, generate a shortlist, score the finalists on a weighted scorecard, and negotiate. Skip the needs definition and you end up buying what looks shiny.

The scorecard exists so a polished demo or a likable sales rep does not decide a multi-year commitment. The product is what you live with for years; the rep will not be there.

Audience: teams selecting a tool or vendor, running an RFP, weighing build versus buy, or deciding whether to renew or switch at a contract renewal.

View the skill on GitHubBrowse the full catalog

The framework

Five phases, skipped at your peril.

A structured evaluation runs in order. The temptation is to skip to demos; resist it.

  1. 01Define the need: the problem, the use case, what success looks like in 6 months and 2 years, the budget range, the timeline, and the must-have integrations. Without this, vendors steer you toward shiny.
  2. 02Build vs buy: decide before evaluating vendors. Build when it is core and differentiating, no vendor fits, and you can maintain it; otherwise buy. Most teams over-build, so the default is buy.
  3. 03Generate the shortlist: cast wide first (5 to 8 candidates from analyst reports, peer recommendations, reviews, adjacent vendors, and open source), then narrow to 2 to 4 finalists.
  4. 04Score the finalists: a weighted scorecard across functional, technical, and operational fit, security and compliance, vendor health, cost, and lock-in risk, scored 1 to 5 and weighted to your situation.
  5. 05Negotiate: most enterprise contracts are negotiable and most are not negotiated. Open on terms rather than price alone, keep the runner-up in play as bargaining power, and be willing to walk.

Scoring the finalists

Seven weighted dimensions.

Score each finalist 1 to 5 on each dimension, multiply by the weight, and sum. The score surfaces the tradeoffs; the scoring conversation matters more than the final number.

  1. 01

    Functional fit (40%)

    Does it do what you need, handle the edge cases, and fit the workflow? The heaviest weight, because nothing else matters if it does not solve the problem.

  2. 02

    Technical fit (15%)

    Integration with your stack, API quality and completeness, data export and portability, and performance at your scale.

  3. 03

    Operational fit (10%)

    Onboarding effort, documentation quality, and support quality tested by submitting a real ticket, plus the SLAs.

  4. 04

    Security and compliance (10%)

    SOC 2, ISO 27001, and the rest as applicable, data residency, encryption, access controls, and subprocessors.

  5. 05

    Vendor health (10%)

    Years in business, funding or revenue, the customer base and similar customers, references, and roadmap visibility.

  6. 06

    Cost (10%)

    License, implementation, training, integration, and the switching cost if it fails. Build a comparable model at your scale.

  7. 07

    Lock-in risk (5%)

    Data export quality, standard versus proprietary formats, migration paths to alternatives, and contract escape clauses.

How to decide

Don't be charmed by the demo.

Buy unless there is a strong reason to build, then question even that reason, because most teams over-build. Build when the capability is core and differentiating, no vendor fits, the economics work at your scale, and you have the team to maintain it; otherwise the vendor's specialization beats your generalism.

The demo is theater. Vendors show their default demo with synthetic data, so bring your own use case and run a trial with real data, take reference calls with customers the vendor did not curate, and start the security and compliance review early, because for enterprise vendors it can take weeks. The scorecard exists so a likable sales rep does not decide a multi-year commitment.

Negotiate terms, not only price. SLAs, exit clauses, and the renewal notice window matter more for long-term satisfaction than a 5% discount, and a multi-year lock without an escape clause is a trap. Keep options open until terms are settled, because a verbal 'yes, we want to buy' removes the vendor's reason to move, and track every renewal so it does not quietly auto-renew at an increase.

Reference files

The reference that goes alongside the SKILL.md.

  • references/evaluation-rubric.md

    The scoring template with weighted dimensions, 1-to-5 criteria for each, and a worked vendor-comparison example.

Browse all reference files on GitHub

Bridges to other skills

What sits around a vendor decision.

Vendor evaluation chooses what to buy. These cover reducing spend on what you already have, the security review of a finalist, and the libraries that are not vendor contracts.

  • Reduce existing spend

    cost-optimization

    Cutting spend on tools already in use is a different exercise. Vendor evaluation decides what to buy; cost optimization audits what is already being paid for.

  • The security review

    security-baseline

    The security and compliance dimension of the scorecard draws on the baseline's checks. Onboarding a new vendor is one of the moments that skill is built for.

  • Libraries, not contracts

    dependency-management

    Pinning a library or runtime is dependency work, not a vendor decision. Vendor evaluation is for the commercial relationship behind a paid service.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.mdBrowse the full catalog

Frequently asked questions.

What are the five phases?
Define the need (the problem, the use case, success criteria, budget, timeline, and constraints), decide build versus buy, generate a shortlist (wide first, then 2 to 4 finalists), score the finalists on a weighted scorecard, and negotiate. Skipping the needs definition and demoing first is the most common failure: vendors are happy to show off, and you end up choosing what looks shiny rather than what fits the actual problem.
Should I build or buy?
Buy unless there is a strong reason to build, and then question even that strong reason, because most teams over-build. Build when the capability is core and differentiating, when the need is so specific no vendor matches, when the economics work at your scale, when you have the team to maintain it, and when vendor lock-in would be unacceptable. Buy when it is table stakes rather than differentiating, well-served by existing products, and the team should focus elsewhere.
How do I compare finalists?
With a weighted scorecard, not demo theatrics or whoever has the friendliest rep. Functional fit carries the most weight (40%), then technical fit, operational fit, security and compliance, vendor health, cost, and lock-in risk. Score each finalist 1 to 5 per dimension, multiply by the weight, and sum. The number is not gospel; it surfaces the tradeoffs, and the scoring conversation matters more than the total, because that is where a disagreement (one person scored the UX a 5, another a 2) gets aired.
What is negotiable in a contract?
More than most teams negotiate. Price (a multi-year commitment commonly earns 15 to 30% off, plus volume tiers, prepayment, and end-of-quarter timing), payment terms, success commitments like training and onboarding, SLAs and their credits, and termination clauses. Negotiating only on price is a mistake, because terms, SLAs, and exit clauses matter more for long-term satisfaction than a 5% discount. Open on terms, keep the runner-up in play as bargaining power, and avoid a multi-year lock with no escape clause for material breach.
How do I avoid lock-in?
Plan the exit at the start rather than after you are stuck. Score lock-in risk explicitly on the scorecard (data export quality, standard versus proprietary formats, migration paths, and contract escape clauses), avoid a multi-year lock without an escape clause, and insist on a renewal notice window longer than 60 days. Tightly integrating into a vendor's proprietary surface with no exit plan is how a switch becomes impossible later, so reserve multi-year commitments for vendors you already trust.