The decision usually arrives as a spreadsheet: three vendors, a build estimate, licence costs down one column and time-to-launch down another. Someone has already formed a preference, and the meeting exists to confirm it.
What the commercial comparison misses
The spreadsheet is not wrong; it is incomplete in a specific, expensive way. Purchase price and build cost are the visible numbers. The real cost of a build/buy/integrate decision lives in eight technical questions the commercial comparison rarely asks — and the cheapest option on the slide is routinely the most expensive on the estate three years later.
The commercial case compares acquisition costs. But a platform capability is not acquired — it is operated: integrated, secured, upgraded, monitored, staffed and eventually exited. For a bought product, the licence is the entry fee; the operating cost is the integration work, the customisation that hardens into unofficial forks, the upgrade treadmill, and the workarounds for the 20% of requirements the product almost meets. For a build, the estimate covers version one; the operating cost is every year of ownership after the launch team moves on.
Neither is an argument for the other side. It is an argument for comparing total operational cost over the capability's life — which requires the technical questions below, answered before the decision, not discovered after it.
The differentiation test
The first question filters all the others: does this capability make us different, or does it make us run?
Build what differentiates — the capability whose behaviour is your product or your edge, where controlling its evolution is the point. Buy what is commodity — capabilities where being exactly as good as everyone else is fine, and vendor scale beats in-house effort. The expensive failures sit in the confusion zones: building commodity (an in-house tool that a product matches feature-for-feature, minus the maintenance team) and buying differentiation (your core edge, now dependent on a vendor's roadmap and commercial terms).
The test is honest precisely where it is uncomfortable: most capabilities are commodity, and a need that feels unique is often closer to commodity than it first appears.
Integration surface and data ownership
Two questions decide whether "buy" quietly becomes "build anyway":
How large is the integration surface? Count the touchpoints the product needs with your estate — identity, data flows, workflows, reporting. A product with a dozen deep integration points is not an off-the-shelf purchase; it is a build project with a licence fee attached. The inventory is a day's work and routinely reshapes the decision.
Who owns the data — practically, not contractually? The contract says the data is yours. The practical questions: in what form can you extract it, at what completeness, with what history, at what cost? A system that holds your data in a proprietary shape owns your exit options regardless of what the contract says.
Lock-in and extensibility as architecture properties
Lock-in is not a vendor sin; it is an architecture property you either manage or absorb. The measurable version is exit cost: what would it take, today, to move this capability elsewhere — data migration, rebuilt integrations, retraining, parallel running? If the answer is "we would never realistically leave", that fact belongs in the decision and in the negotiation, priced accordingly.
Extensibility is the same property facing forward: when your requirements outgrow the product's 80%, what happens? Products with real APIs, extension points and a supported customisation model age well. Products where extension requires vendor professional services tie your roadmap to their delivery capacity and pricing. For builds, the mirror question is who extends it in year three, when the original team is elsewhere.
Security and compliance surface
Each option carries a different security posture, and the comparison is rarely made explicit. Buying imports a vendor into your trust boundary: their access model, their patch cadence, their incident history, their subprocessors — due diligence, not a checkbox. Building keeps the boundary internal but makes you responsible for everything inside it, including the parts a vendor would have staffed. Integrating — composing the capability from existing trusted systems — can reduce the number of new components, but the integration paths themselves still need explicit security review.
For regulated estates, this question alone can decide the matter before cost is discussed.
The scorecard
Eight questions, scored with evidence before the commercial decision:
- 1. Differentiation — does this capability make us different, or make us run?
- 2. Total operational cost — over the life of the capability, not the acquisition.
- 3. Integration surface — how many touchpoints, how deep, priced as engineering.
- 4. Data ownership — practical extractability, not contractual reassurance.
- 5. Lock-in / exit cost — what leaving would take, in numbers.
- 6. Extensibility — what happens after the 80% runs out.
- 7. Security surface — what enters the trust boundary, who patches it.
- 8. Time-to-capability — honest, including integration and adoption, not time-to-contract.
The frequent outcome is not a verdict but a decomposition: buy the commodity core, build the thin differentiating layer on top, integrate the rest through owned interfaces. The hybrid answer never appears on a vendor slide, because nobody is selling it — which is precisely why it needs an engineering voice in the room before the signature.