Build vs. integrate

This lesson is written from the buyer's side of the decision as much as the seller's, deliberately: understanding when a prospective client's honest answer is "don't build this, buy something and configure it" is what makes a vendor's pitch credible in the first place, and it's a defensible, common answer among people who study this seriously — not a hedge.

---

#The framework, stated simply

The clearest single test, converging across multiple build-vs-buy frameworks — Gartner's own guidance moves past a strict binary toward what it calls a "buy, build, and blend" model; McKinsey's make-or-buy research frames it around whether a capability is a genuine competitive differentiator — is this: is this capability "standard for the industry," or is it "the way we win"? If a function is something every competitor in the buyer's industry needs and none of them gain advantage from doing differently — payroll processing, basic CRM, standard ticketing — buying and configuring an existing platform is almost always the right call, because building it from scratch spends real engineering time reproducing something that creates no competitive advantage once finished. If the function is genuinely core to how the buyer wins — the thing their business is actually differentiated on — the case for building it, or at least owning a proprietary version of it, gets much stronger. [Established] as a standard, well-corroborated strategic-technology framework across multiple named analyst and consulting sources.

#The honest, disclosed cost of getting this wrong

This isn't an abstract framework question — there is real, disclosed data on how badly large custom-software projects go over their plan. A joint McKinsey Digital and University of Oxford study, drawing on more than 5,400 IT projects (defined as projects with an initial price tag above $15 million), found that large IT projects run 45% over budget and 7% over schedule on average, while delivering 56% less value than predicted. Extreme outliers are common too: roughly 17% of large IT projects ran cost or schedule overruns severe enough to threaten the sponsoring company's viability. [Established] — a named, disclosed-methodology study from a credible research collaboration (McKinsey Digital and Oxford's BT Centre for Major Programme Management), not a marketing claim; note this specific research dates to 2012 and is still the most-cited figure of its kind in this space, so treat the direction as durable but re-check for more recent equivalent research before quoting the exact numbers as current.

This is the honest grounding for a position held by many credible technology-strategy voices: that custom software is usually the wrong answer for a given capability — not because building is impossible, but because the base rate of large custom builds meaningfully underdelivering against their own plan is real, disclosed, and severe. A vendor or consultant arguing for a custom build has to clear that base rate, not just argue the alternative platform has gaps.

#A live, contested data point worth naming carefully

A widely-reported 2025 MIT research finding is directly relevant here and gets its own full, tiered treatment in Module 4's second lesson (the pilot-to-production gap) — but the specific build-versus-buy finding belongs here too: that same research reported that enterprises pursuing AI capability through vendor partnerships and purchased tools succeeded roughly twice as often as those attempting to build the equivalent capability entirely in-house. [Directional — see Module 4 for the full tiered treatment of this study, including named methodological criticism]. Flagged here specifically because it's a live, contested data point about exactly this lesson's question, not a settled one — read the fuller treatment before repeating the "2x" figure on its own.

#When custom genuinely wins

None of the above is an argument that custom development never wins — it's an argument that it has to clear a real bar. The honest cases where it does:

• The capability is genuinely the buyer's differentiator, not a commodity function — per the framework above.
• No off-the-shelf platform's data model or workflow fits the buyer's actual process, and configuring around the mismatch would cost more, in ongoing operational friction, than building the right thing once.
• The buyer's scale or regulatory position makes vendor lock-in itself the risk — a large enough buyer sometimes has good reason to prefer owning the system outright over depending on one vendor's roadmap, pricing power, and continuity.
• An existing platform genuinely doesn't exist yet for the specific function — rarer than most build-vs-buy conversations assume, but real, especially in enterprise AI (Module 4, next).

#The honest sales implication

A seller who can correctly and visibly tell a prospect "you don't need custom for this, here's what to configure instead" on the functions that don't clear the bar above is making the case, by demonstration, that they can be trusted on the functions where they do recommend building. This isn't altruism — per the McKinsey-Oxford data above, a custom build the buyer didn't actually need is a project both sides are statistically likely to regret, and a seller whose reputation survives past one contract needs the buyer's honest assessment of value, not just the signed deal.