Evaluating Vendor Deployments

Imagine a consulting firm that has spent years selling strategy reports and advisory projects. One day its marketing team relabels those same services as Full-Stack Development Engagements, or FDE, and publishes a polished page about the new offering. A buyer reading that page could reasonably conclude that the firm now builds and ships software for its clients. The title suggests a capability, so the buyer assumes the capability exists.

This article is about that assumption. A vendor who presents itself as doing FDE work has not yet shown anything about what it actually does. The label is a claim, and claims are cheap to make. The useful question is what evidence sits underneath the label, and that question can be answered before any contract is signed.

Follow the chain of reasoning in the consulting firm example one link at a time. Step one: the firm changes the name of its offering to FDE. Step two: the firm publishes a page describing that offering. Step three: the buyer reads the page. Step four: the buyer concludes that software is being built and shipped. Only the first two steps are things the firm has done. The fourth step is something the buyer has inferred, and nothing in steps one through three forces that inference to be true.

The source places the substance of FDE in the code that ships. The marketing about FDE is a separate activity, and it happens regardless of whether that code exists. This separation is the central point. A vendor can generate a role title, a brochure, a case study layout, and a sales pitch on any schedule it chooses. None of those artifacts requires a deployment to be running somewhere.

A deployment is different in kind from a document. The source describes deployments that run in a customer's environment as taking real effort, and says they cannot be written into existence the way a brochure can. That difference is why the source treats documents as an unreliable signal on their own. Documents may be accurate, but a reader has no way to confirm from the document alone that the work behind it happened.

The source also observes a pattern from the past two years: most new entrants into the FDE category have produced documents rather than deployments. It singles out larger incumbents adapting from a consulting background as a notable group. These firms have strong sales and marketing machinery, so they can describe a new offering quickly and convincingly. Speed and polish of the description are therefore not evidence of the capability being described.

When a vendor is evaluated, the evidence it offers usually falls into one of two groups. The first group is documentary: decks, case studies, and public pages. The second group is deployment-backed: production systems the vendor has built for earlier customers, which the vendor can open up and explain. The source's point is that only the second group bears on whether FDE work is actually happening.

Read the comparison column by column. The left column holds what a document-only vendor can offer. Every item there can be produced without any customer system existing. The right column holds what a vendor with real deployments can show, and each item there depends on code that actually runs. The two columns can look similar on a sales page, which is exactly why the customer has to ask for the right column directly.

The practical test follows from the definition. Before signing a contract, a customer asks the vendor for the production deployments it has made for previous customers. The decision then branches. If the vendor can produce those deployments and walk the customer through the running code, the vendor has passed the check the source describes. If the vendor cannot, it belongs in the group that offers only decks and case studies, which the source says is not doing the real work, however the role is named.

Notice the order of the steps. The request for deployments comes before the contract is signed, not after. Asking late removes the buyer's leverage and makes it harder to back out if the answer is unsatisfactory. The decision point is the single question of whether a deployment can be produced. A yes leads to a code walkthrough. A no places the vendor in the decks-and-case-studies group.