Concepts / Assessing Vendor Capability

Assessing Vendor Capability

Slide decks and case studies describe a vendor's work but do not demonstrate a running system, and the source treats them as signs of a consulting motion rather than an FDE motion.

  • Programming

Why a Polished Pitch Is Not Enough

Vendors who sell forward deployed AI work often arrive with polished material: a deck that explains their approach, a handful of case studies with headline outcomes, and a confident account of what their team can do. When you are deciding whether a vendor can actually deliver, it is tempting to treat that material as proof. This article examines that common belief and replaces it with a more reliable test.

What do you think happens?

A vendor shows you an excellent slide deck and three case studies with strong results, but cannot show you any system it has built for another customer. Does that material establish that the vendor is doing FDE work?

  • Yes, a deck and strong case studies settle it

  • No, the deck and case studies cannot settle it

Reveal answer
Answer:

No. The deck and case studies do not establish FDE work, because they do not show a running system.

A deck describes the work and a case study narrates past results. Neither lets you watch a system operate, check how it responds to real inputs, or see whether anyone is monitoring it. The source treats this kind of material as a sign of a consulting motion rather than an FDE motion.

What Each Artifact Lets You Verify

The reason a deck cannot settle the question comes down to what each artifact lets you verify. A slide deck is written by the vendor to describe its work. A case study is a narrative about past results. Both are produced to present the vendor well, and neither lets you check the work yourself.

The gap between a description and a working system is exactly the gap this review is designed to expose. Describing a system and operating one are different claims. A description can be accurate, but it cannot show you how the system behaves when real inputs arrive, or whether anyone watches it after it goes live.

The Direct Request for Shipped Code

The review begins with a direct request. The source gives the wording to use: ask the vendor to show the production code it has shipped for a previous customer. The request is specific on purpose, and each part of it does work.

  • Shipped means the code has left the vendor's own workspace and entered a customer's environment. Work that exists only in a demo or internal repository has not shipped.
  • Production means the code is the version actually used in operation, not a prototype or a sample built for the sales process.
  • Previous customer means the code runs for someone else, so the vendor cannot claim the work is only prototypal or internal.

The source is direct about timing: do not sign the contract until you have seen the running code. The key evidence is a system currently running in another customer's environment, and the vendor should be able to walk you through it.

Two Motions, Two Kinds of Evidence

The difference between an FDE motion and a consulting motion shows up in what the vendor can put in front of you. The comparison below summarizes the contrast the source draws. It is about the evidence a vendor is able to show, which is what makes it useful during a review.

Running productioncodein another customer'senvironmentSlide deckdescribes the vendor'sapproachEval evidence anddashboardwalked through inside thesystemCase studiesnarratives of past headlineresultsOperationalinstrumentationshows monitoring inoperation
Which kinds of vendor evidence belong on the FDE side and which on the consulting side, and how do they differ?

On the FDE side, the strongest evidence is the running system itself. A thorough walkthrough covers eval evidence, the dashboard, and operational instrumentation. Together these show that the system is measured and monitored in operation, not merely built. On the consulting side sit the materials the vendor writes to describe its work: the deck and the case studies. The source treats these as signs of a consulting motion rather than an FDE motion.

Walking Through the Review Step by Step

The review proceeds in a fixed order, and the first question decides which path you follow. The flow below shows the sequence from the vendor's claim to the decision about signing.

Ask for shippedproduction codefor a previous customerRunning for anothercustomer?can the vendor show it nowWalk through evalevidenceinside the running systemReview dashboard andinstrumentationconfirm monitoring inoperationExamine evidence inthe running systemcontinue the reviewDo not sign on thepresentation alonetreat as consulting signalvendor respondsyesno
When a vendor presents a claim, what checks happen in what order, and what does the buyer do at each branch before the contract is signed?

The first branch is the most important. A yes moves the review toward examining the evidence inside that system. A no places the vendor in the category the source associates with a consulting motion, and the contract should not be signed on the strength of the presentation alone.

Applying the Review to a Vendor Scenario

Worked example

A vendor with a strong deck and no running system

A vendor offers to build a forward deployed AI system for your organization. It sends a polished deck, three case studies with strong headline results, and a confident description of its team. When you ask for the production code it has shipped for a previous customer, it says the work is proprietary and offers another slide deck instead. Should you sign?

  1. 1
    Identify the claim

    The vendor claims it can deliver FDE work. The only supporting material so far is a deck and case studies.

  2. 2
    Apply the direct request

    You asked for shipped production code for a previous customer. That request targets exactly the evidence that would show a running system.

  3. 3
    Take the first branch

    The vendor cannot show a system currently running for another customer, so the answer at the first decision is no.

  4. 4
    Follow the no path

    The vendor falls into the category the source associates with a consulting motion. The contract should not be signed on the strength of the presentation alone.

  5. 5
    Note what the offer changed

    Offering another deck does not answer the request. It is more of the same kind of material, which does not let you watch a system operate.

Result

Do not sign. The deck and case studies do not demonstrate a running system, and the vendor has not produced the evidence the review requires.

Mistakes Buyers Make in This Review

  • Common mistake

    Treating a polished deck as proof of delivery

    Why it fails

    A deck is written by the vendor to describe its work. It does not let you watch the system operate or check how it responds to real inputs.

    Do this instead

    Ask for the running system and treat the deck as a description to be checked, not as evidence.

  • Common mistake

    Accepting case studies with headline outcomes as sufficient

    Why it fails

    A case study is a narrative about past results. It does not show whether the system is currently running in another customer's environment.

    Do this instead

    Request the shipped production code and ask the vendor to walk you through the system that is running today.

  • Common mistake

    Signing before seeing the running code

    Why it fails

    The source is direct that the contract should not be signed until you have seen the running code.

    Do this instead

    Make the viewing of running code a precondition of signing.

  • Common mistake

    Accepting a walkthrough that covers only the code

    Why it fails

    A thorough walkthrough covers eval evidence, the dashboard, and operational instrumentation. Those together show the system is measured and monitored in operation.

    Do this instead

    Ask about evaluation results, the dashboard, and instrumentation, not only the source code.

Practicing the Review Before a Signing Decision

MEDIUM

A second vendor sends a deck and two case studies. It says its system is running for a previous customer but declines to show the code, citing confidentiality, and offers a recorded presentation about the system instead. Using the review, decide which motion the evidence points to and what you would require before signing.

Hints
  • Start with the direct request: what exactly did you ask for, and what was offered instead?
  • Ask which items on the comparison are about a running system and which are about descriptions.
  • Think about the first branch of the flow: can the vendor show a system currently running for another customer?

Key Takeaways

  • A deck and case studies describe a vendor's work but do not demonstrate a running system, and the source treats them as signs of a consulting motion rather than an FDE motion.
  • The key evidence is a system currently running in another customer's environment, which the vendor should be able to walk you through, including eval evidence, the dashboard, and operational instrumentation.
  • Ask for the shipped production code for a previous customer, and do not sign the contract until you have seen the running code.
  • If the vendor cannot show a system currently running for another customer, the contract should not be signed on the strength of the presentation alone.