Decisions · 6 min read
Build vs. Buy is no longer enough
Two answers were adequate when building was slow and expensive. The decision now has at least eight, and naming the right one is worth more than negotiating the wrong one.
Build vs. Buy became the default framing for a practical reason: for most of the last three decades those really were the two options, and the arithmetic between them was stable. Building was slow, staffing-intensive, and risky. Buying was faster, cheaper at the point of decision, and came with someone else's roadmap. The framing survived because it described the world.
It describes the world less well now. When useful working software can exist in weeks rather than quarters, several options that were previously uneconomic become genuinely available — and several that looked obvious become worth re-examining. A binary question forces a portfolio of different situations into one of two boxes.
A more honest list has at least eight entries. Buy, when a commercial product solves the problem well enough. Build, when the problem is specific to the organization and worth owning. Co-Build, when the internal capability to continue matters as much as the software. Automate, when the problem is a workflow before it is an application. Integrate, when the capability already exists in systems that do not talk to each other. Modernize, when the system is sound in intent and constrained by its implementation. Retire, when the system persists out of habit rather than value. Defer, when the evidence does not yet justify a commitment of this size.
The point of the longer list is not to encourage more custom development. Several of these answers involve building nothing. The point is that the decision deserves the same rigour later applied to the implementation, and it rarely receives it — because by the time an implementation partner is selected, the decision has usually already been made implicitly by whoever framed the options.
Our objective isn't to build more software. It's to make better software decisions. That is a commercially inconvenient position to hold, because it means recommending against work we could otherwise do. It is also the only version of the argument worth making, since the alternative is a vendor whose recommendation is knowable in advance.