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.
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?
Reveal 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.
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.
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
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?
- 1Identify the claim
The vendor claims it can deliver FDE work. The only supporting material so far is a deck and case studies.
- 2Apply 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.
- 3Take the first branch
The vendor cannot show a system currently running for another customer, so the answer at the first decision is no.
- 4Follow 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.
- 5Note 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.
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 failsA 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 insteadAsk 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 failsA 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 insteadRequest 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 failsThe source is direct that the contract should not be signed until you have seen the running code.
Do this insteadMake the viewing of running code a precondition of signing.
Common mistake Accepting a walkthrough that covers only the code
Why it failsA thorough walkthrough covers eval evidence, the dashboard, and operational instrumentation. Those together show the system is measured and monitored in operation.
Do this insteadAsk about evaluation results, the dashboard, and instrumentation, not only the source code.
Practicing the Review Before a Signing Decision
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.