The decision is whether to build something internally or acquire it externally. And the failure mode is almost always the same: the organization defaults to building it internally, not because that is the right answer for the program, but because that is what the team knows how to do.
Why the Default to Build Is a Problem
Research and development organizations tend to develop a strong internal orientation over time. They hire technically capable people, build institutional knowledge, and accumulate tools and processes that reflect their accumulated experience. This is appropriate — it is what makes an R&D function effective.
But that same orientation becomes a liability when it hardens into a reflexive assumption that every component, every subsystem, and every capability required for a new product should be developed internally. Organizations that operate under this assumption consistently underestimate the cost, time, and organizational attention required to develop capabilities from scratch. They often produce inferior first-generation products as a result, because the internal capability they built to replace an external option was not yet mature when the product needed it to be.
The make vs. buy decision is not a procurement question. It is a strategic question — and it deserves to be treated as one.
What the Decision Actually Involves
A disciplined make vs. buy analysis asks several distinct questions, each of which has to be answered honestly before a conclusion can be drawn.
The first is a capability question: Does the organization currently have the technical competency, the tooling, the process knowledge, and the quality infrastructure to develop this component or capability to the standard the product requires — on the timeline the program demands? Not eventually. Now.
The second is a cost question: What is the fully loaded cost of developing this internally — including the engineering time, the capital investment, the quality and regulatory validation, the opportunity cost of the people and resources diverted from other priorities — compared to the cost of acquiring it externally? Organizations routinely underestimate internal development costs because they do not account for all of them.
The third is a strategic question: Is this component or capability part of the organization’s core value proposition to customers? If the answer is yes, internal development may be worth the investment — because the capability becomes a durable competitive advantage. If the answer is no — if this is a commodity component, a supporting technology, or a capability that exists at high quality in the external market — then internal development is consuming resources that should be deployed elsewhere.
The fourth is a risk question: What is the development risk of building this internally, and what is the supply risk of depending on an external source? Both carry risk. The question is which risk is more manageable given the program’s timeline, budget, and technical maturity.
The Partners Organizations Consistently Underutilize
Across product development engagements, MKA has observed that two functions are consistently excluded from make vs. buy decisions too early, at significant cost to the program.
The first is sourcing. Organizations that engage sourcing teams early — before design direction is locked — benefit from market intelligence about what exists externally, at what quality level, and at what cost. Sourcing teams that are brought in after design is complete are left to execute a procurement plan that was never designed for procurement efficiency. The design constraints that were locked in without their input often make external sourcing more expensive or technically infeasible.
The second is legal. Intellectual property implications of make vs. buy decisions are frequently overlooked until they become problems. Whether the organization is licensing technology from a third party, developing on top of a platform that belongs to a partner, or acquiring a component that might be incorporated into a product with regulatory submission requirements — the IP architecture of a development program is shaped by make vs. buy decisions, and legal should be part of making them.
Make vs. Buy Across the Development Lifecycle
The make vs. buy question is not answered once at program initiation and then closed. It recurs at multiple points in the development lifecycle, and the right answer can change as the program matures.
At the earliest stages, when requirements are still forming, the decision set is widest. The organization has the most flexibility to choose between internal development, external supply, and partnership or licensing arrangements — and the cost of changing direction is lowest.
As the program progresses into detailed design and engineering, the decision set narrows. Choices made in early phases constrain later options. A design that was built around an internally developed component cannot easily be redesigned around an external alternative when the internal development runs late or underperforms. This is why early sourcing engagement matters: it preserves optionality at the moment when optionality is most valuable.
At the manufacturing and integration phase, the question shifts from component-level make vs. buy to process-level decisions: which manufacturing steps should be performed internally, which should be outsourced to a contract manufacturer or process development partner, and what the quality and regulatory implications of those choices are.
The Cost of Getting It Wrong
The organizations that consistently struggle with make vs. buy decisions share a common pattern: they make them implicitly, without a structured analysis, and they make them too late — after significant internal development effort has already been invested, creating the same sunk-cost dynamic that makes portfolio kill decisions so difficult.
By the time it becomes obvious that an internal development effort is underperforming — that the component is not meeting specification, that the timeline has extended by six months, that the team does not actually have the expertise to solve the problem they are facing — the cost of switching to an external source has multiplied. The design has to be revisited. The timeline has to be reset. The program absorbs both the cost of the failed internal effort and the cost of the external acquisition that should have been the first choice.
The make vs. buy decision is not about whether the organization is capable of building something. It is about whether building it is the right deployment of the organization’s finite resources, at the right time, for the right program. That is a strategic question — and organizations that treat it as one make better products, on better timelines, at better cost.
MKA Insights works with life sciences and medical device organizations on product development strategy and NPD process design. Contact us.