Is “Build” vs “Buy” necessarily a dichotomy, or can you do both?

What's the problem you're trying to solve? That's the true question to be addressing.

Companies should have a list of underlying principles that guide their Tech decisioning. Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

One of those rules may very well be buy over build.

But if you have an internal dev shop then buy might come under build.

Neither is wrong, unless it is in breach of your principles.

IT is far too complex to be answered in a binary A or B answer. Those types of questions are often self-serving.

Many times technology requires a hybrid approach, which in the long-term, is much more effective.

Almost always do both. Even when building there are components to buy & leverage. There are exceptional mission spaces, and it’s good to evaluate the trade offs in value, but if the decision is always build or buy, it’s fairly unique.

Generally the challenge statement is defined first. It is then vetted through a build, buy, or partner approach. We are not a software company, don’t intend to be, but we have core competencies. We only bring in when there is a gap in competency that meets a strategic goal or brings value that didn’t exist before. We only build where it complements an existing program. Reducing the tech debt is important.

The answer is it depends, depends on several factors such as business area, stage at which the company is, how critical this problem is? 
Example: Do you want to build your own billing system, most of the time answer is No, but if are a multi-billion $ company, most of the solutions do not work for you (you tried it in the past) then build may be an option.