Buy-versus-build arguments are almost never settled by the evidence in the room. They are settled by what the room believes about control, and the evidence is arranged afterwards to agree. That is easy to assert and hard to prove, because the losing option usually leaves no trace worth reading. This blueprint left one, because the instrument it used to compare options was precise enough to be counted after the fact.
A global staffing and HR services group was choosing the components of an integrated digital platform to sit above a fragmented, locally tailored estate. Rather than reconcile five vendor feature lists, the assessment drew one canonical map of the capabilities the business needed, 36 of them spanning what people experience, what the data has to do, and what has to be joined up underneath, and then shaded each candidate's coverage onto identical copies of that same map. Five pictures of one shape. The comparison is honest in a way a feature list is not, because the shape does not change to suit whoever is presenting.
The shading was never totalled on the slides. Counting it produces a ranking that does not match the recommendation.
The challenge
The ready-made third-party recruiting product, the option that would have been bought rather than assembled, covered 24 of the 36 capabilities. That is the highest coverage of any single candidate. The three components named in the recommended hybrid, the experience capability that carries the candidate and client journey, the automated workflow capability that carries straight-through processing, and the shared data capability underneath both, covered 23 each.
One capability ahead is not much on its own. The distribution matters more than the total. Three capabilities on that map were covered by the bought product and by none of the other four: running commercial relationships with other firms, handling service failures against agreed service levels, and taking steps out of a process. Nothing in the recommended hybrid covers any of them.
The bought option is not struck from the blueprint. It appears once, as a noun in the end-state list on the summary page, alongside the components that were argued for. What it never receives is a place in the recommendation itself, a position in the sequence, or a sentence about what happens to those three capabilities until it arrives.
The contrast that makes the point sharpest is the customer-relationship option. It covered 18 of 36, the weakest of the five, and every one of those 18 was already covered by the three components chosen. Its marginal contribution to that architecture is zero. The recommendation names it anyway, explicitly deferred to the longer term to complete a single view of clients and candidates, which is a capability the assessment's own shading shows three other options already cover. So the option that adds nothing to the chosen set gets a timing and a stated reason, and the option that is the sole cover for three capabilities gets neither.
That asymmetry is the finding. It is not evidence of a bad decision. It is evidence that capability coverage was not the variable the decision turned on.
The approach
The written evaluation of the bought product is unusually straight about what the real objections were, which is why this piece can be written without guessing. Four strengths were recorded: advanced recruiting features available immediately that are difficult and expensive to build and maintain in-house, faster time to market for new features, proven live-tested concepts that reduce trial and error, and significant cost reduction against building the same thing internally. The stated purpose of buying was to free internal people to concentrate on advice and on client and candidate service.
Four weaknesses were recorded against them. The features would not be unique to this market unless developed bespoke on top. Standard features and workflows can be hard to fit to an existing business model and to existing governance. One size does not always fit all. Integrations back to the finance and sales systems can be a larger task.
Read that list again with the capability map beside it. Only the last objection is technical, and it is a scoping concern rather than a gap. The other three are all the same objection stated three ways: what you buy, everyone can buy, and it will not bend to how we already work. That is a legitimate argument. In a business whose competitive claim rests on matching and on service, wanting the matching to be yours is a defensible strategy, and the assessment says so in its own terms when it rates the bought option able to deliver a good experience but not the best available.
What the assessment does not do is price that preference. Nowhere does it say what the differentiation is worth, what the three uniquely covered capabilities cost to obtain elsewhere, or how long the internal build of the equivalent features would take before it reached parity with something already live. The uniqueness argument carried unpriced, against an option that arrived with more coverage than anything else on the table.
The two percentages attached to the bought option deserve careful handling, because they are the only percentage figures anywhere in the component assessment. The example use case carried into the comparison reports mobile traffic up 97 per cent and job application rates up 68 per cent, attributed to research on the user journey and to better job alerts rather than to the product itself. Two independent numbers, traffic and conversion, moving from one intervention.
They are also vendor-side evidence offered inside an option assessment. They are not this group's results. Nothing in this blueprint records a purchase, an implementation or a measured outcome, and it would be dishonest to present those percentages as anything other than what they are: the strongest evidence in the room, attached to the option the recommendation declines to argue for, and never tested here.
The outcome
What this phase produced is a recommendation. The chosen answer was a composition rather than a product: an experience capability for the candidate and client journey, an automated workflow capability to carry straight-through processing, both resting on a shared data capability because neither works without clean data underneath, with the customer-relationship component set for later. No system was bought in this phase. No coverage figure quoted here is an outcome. They are readings taken off a scoring instrument.
The lesson is worth naming plainly, because it generalises past this estate. When an organisation compares buying a capability against assembling one, the assembled option tends to win on arguments that are never scored, and the bought option is asked to clear a bar the assembly is not asked to clear. Nobody in this assessment asked which capabilities the hybrid would fail to cover, or what the three unscheduled ones would cost to recover later, or how many quarters of internal work sat between the recommendation and the coverage the bought option had on day one.
Anyone deciding today whether to build their own retrieval and copilot platform or licence one is standing in exactly this room. The bought option will be described as generic and hard to fit, and both will be true. The built option will be described as differentiating, and that will also be true, right up to the point where the differentiation turns out to live in the data and the evaluation sets rather than in the platform. Our Consult work starts by forcing the same discipline the coverage map imposed here: write down what you need, score every option against the identical list, and then, if you still choose to build, record in writing which capabilities you have chosen to defer and what you expect them to cost when you come back for them.
The evidence did not lose this argument. It was simply never asked to settle it.