Build vs buy is the wrong question
I have sat through a lot of build vs buy debates. They follow a predictable pattern. Someone presents a shortlist of vendors. Someone else argues the vendors cannot do what is needed. A third person suggests building it in-house. The debate becomes about capability and cost without ever establishing what the decision is actually for.
Build vs buy is the wrong framing. It produces the wrong debate and, consistently, the wrong outcome.
Why the build vs buy framing fails
The build vs buy question treats the technology decision as the primary decision. It asks: should we build this capability, or should we buy it from a vendor? But that is the second question. The first question, which most organisations skip, is: should we be differentiating in this capability at all?
If a capability is not a source of competitive advantage, building it is waste. If a capability is genuinely differentiating, buying a commodity solution that cannot support differentiation is a strategic mistake. The build vs buy debate regularly reaches the wrong answer because it begins with the solution rather than with a clear view of what is strategic and what is not.
The question that actually matters
The useful version of the build vs buy question is: what is the minimum viable ownership model for this capability that preserves the ability to differentiate where differentiation matters? That question opens up a more useful decision space. You might configure a vendor product rather than build. You might integrate multiple vendor products. You might build only the layer that is genuinely proprietary and use commodity components everywhere else. You might buy now and plan a structured transition to a build model once the differentiation requirements are clear.
None of those options appear cleanly in a binary build vs buy framing.
What makes the decision well-structured
A well-structured build vs buy decision has four inputs. First, a clear view of which capabilities in this domain are sources of competitive advantage and which are commodity. Second, an honest assessment of the ability to build and sustain software, not just to deliver a first version, but to maintain, evolve and operate it over a ten-year horizon. Third, a total cost of ownership model that includes the cost of the vendor relationship, integration, customisation, and exit over the same horizon. Fourth, an architectural view of where proprietary logic needs to live and what can safely be abstracted behind a standard interface.
With those four inputs, the decision is usually much clearer than the build vs buy debate suggests. Without them, the organisation is picking a direction without a map.
