"Building it yourself is always more expensive." That is the sentence that ends the discussion in most mid-sized companies before it has even begun. And it is even true — as long as you only look at the first number. The licence for the standard software is right there in the quote, in black and white, comparable, signed off. What building it yourself costs is an estimate loaded with uncertainty. One of them sounds like risk, the other like safety. Except this comparison leaves out the most expensive item of all: the customisation effort the standard solution causes over five years, because in two or three places your process simply is not the standard.
For the IT manager, Build vs. Buy is not an academic question. It is the decision he has to answer for in front of management — and not today, but three years from now, when the chosen system either runs quietly or quietly grinds. If he buys standard and the process does not fit, he spends years bending operations around the software or paying for every special case as a customisation project. If he builds it himself and underestimates the running of it, he ends up with a system that only works as long as the right people are around. Both mistakes are expensive. Both happen because the decision is treated as a matter of faith instead of a calculation.
Why the Decision Is So Often Framed Wrong
In most companies, Build vs. Buy is negotiated as a question of camps, not a question of substance. There is the standard camp — usually driven by the understandable wish not to have to run anything themselves, and by the argument that "a thousand others use it too." And there is the in-house camp, often the team itself, who knows exactly where the standard does not fit and who bristles at a bought-in straitjacket. Both are right, and both are wrong — because the question is not actually "either/or." It is: at which specific points does our process deviate from the standard, and what does exactly that deviation cost us over the next five years?
It is a boring question. It has no punchline, it is useless for a matter-of-principle debate, and it forces both camps to trade their conviction for a list. That is exactly why it is asked so rarely. It is more comfortable to pick a side and write the other off as naive than to name honestly the two or three places where your own business ticks differently from the market. But those two or three places are the entire decision. Everything else is taste.
Build vs. Buy is not a matter of faith.
A Project Where the Numbers Tipped
In one of our projects, a mid-sized manufacturer faced exactly this decision. It was about order processing, roughly 7,000 orders a month, and on the table lay an established standard solution. The licence was clearly costed, the vendor solid, the demo convincing. The internal estimate for building it in-house was considerably higher — at first glance an open-and-shut case. The IT manager was supposed to sign off on "Buy" and had a bad feeling he could not put a number on.
So we did not talk about the licence. We walked through the process and asked: where exactly do you do it differently from everyone else? Three places came out. A homegrown logic for batch and residual-quantity management, built up over years, that no standard maps that way. A special pricing arrangement for around forty key accounts that cuts straight across the normal pricing logic. And a handover to production planning that has worked in a very specific way in-house for years and that nobody wanted to touch, because half the shop floor hangs off it.