Build vs. Buy Is the Wrong Question

“Build vs. buy” sounds like the decision. It isn’t. It is a proxy for a budget conversation: building is expensive and slow, buying is cheap and fast, so buy. That framing answers the wrong question and hides the one that matters.

Why build-vs-buy misleads

The frame compares cost and time, where off-the-shelf almost always wins. It ignores fit, where it often loses. It also treats “buy” as free of build cost, when buying a near-fit means a build anyway: the workaround layer, the integrations, the people who maintain the gap. The real choice was never build or buy. It was fit or bend.

The real axis: fit vs bend

Every piece of software either fits your process or makes you bend your process to it. Bending has a price you pay forever, the near-fit tax. Fit has a price you pay once. So the question is not “is building expensive?” It is “is this process worth fitting, or cheap to bend around?”

The decision in two questions

Two questions settle it. First, how core is this process to how you actually compete? Second, how large and permanent is the gap between the best available tool and how you work? Plot those two and the answer falls out: a commodity process with a small gap is a buy; a core process with a large, permanent gap is a build you should own. The middle is where judgment lives, the place an honest fit assessment earns its fee.

Using the framework

Run every “should we build this?” through the two questions before the budget conversation. Most things are buys and you should buy them without guilt. The few that are core and badly fitting are where owning the software changes the business. Decide on the axis that matters and the budget conversation becomes a consequence, not the whole debate.

A two-week Fit Assessment plots your decision on the fit-vs-bend axis and returns the call with the numbers attached.