Make or buy: build it yourself, buy it in, or partner

Why isn't a cost comparison enough?

Because it compares a snapshot and ignores the question of capability. Two examples show where it falls short.

First scenario: a supplier calculates in-house production of a component at €11, while buying it in costs €9. The math says buy. But if that component carries the tolerance customers choose you for, buying it in means handing over the very reason you get the order. Five years from now, the supplier knows your customer.

Second scenario: a machine builder develops its own operating software because the in-house electronics department has spare capacity. The comparison only counts development hours. It leaves out maintenance over ten years, training, security updates, and the people permanently tied up handling new requirements.

So the useful question is: what do customers choose us for? Whatever feeds into that stays in house. The rest gets sourced, regardless of who could do it cheaper.

One argument comes up regularly in these discussions and holds up less often than people think: spare capacity. "The machine is running anyway" weighs today's utilization against a commitment lasting years. If you need that capacity in two years, you'll pay for the in-house build twice, in orders you had to turn down. Spare capacity justifies a pilot run, not a permanent decision.

Which four criteria matter beyond price?

You can lay them out side by side in a table, which makes the decision easy to follow, even when it goes against the numbers.

Reversibility is the one most often overlooked. Building in house ties up people; sourcing ties up contracts. Both can be ended, but at very different cost. That difference belongs in the decision.

What belongs in the math for an in-house build?

More than development hours. Four items are missing from most internal calculations.

• Maintenance over the life cycle. A piece of software or a custom component stays with you for ten years. Maintenance costs a share of the development budget every year and ties up the same people.
• Dependence on individuals. If two people understand the solution, that's a risk with a name on it. Documentation and a third person cost extra.
• Forgone alternatives. The people doing the development aren't working on anything else. This item shows up in no calculation, and when development capacity is tight, it's the largest one.
• Ramp-up time to maturity. The first version isn't the one you take to market. Two iterations are normal.

Add these four items and an in-house build rarely comes out cheaper than buying in. It's still the right call when the first criterion in the table above applies.

Buying in also carries costs that aren't in the price. Integration into your processes, dependence on the supplier's schedule, the effort for quality control at goods receipt, and the question of who is liable to the customer when the purchased part fails. With software, add interface maintenance and version upgrades. An honest comparison puts both lists side by side instead of opening only one.

When is a partnership the better route?

When you need the capability but don't need to own it, and when the partner has a stake in the outcome.

Typical cases in mid-sized companies: a software component that complements your product. A service you want to offer alongside it without building up staff. Access to sales channels in a market where your name means nothing.

That said, a partnership is only as good as its exit clause. What happens if the partner is sold, if it takes on your competitor, or if its priorities shift? Those three cases belong in the contract before the first project starts.

And a practical rule of thumb: if more than a fifth of your revenue depends on a partnership, it's no longer a partnership. It's a dependency, and it should be treated like one, with a second option in the background.

How does your leadership team decide?

With a proposal that describes both paths, and with one person who decides. Group discussions rarely settle questions like this, because both sides have good arguments.

One page with five points has proven effective: the task, the two paths with costs over five years, the four criteria from the table with an assessment, the recommendation, and the question of what conditions would trigger a reassessment. That last point takes the heat out of the discussion, because no one is deciding for eternity. A page like this takes two hours to write once the numbers are in, and it still reads clearly a year later.

Watch out for one pattern that shows up regularly: if the department that wants to build also writes the proposal, the comparison will favor in-house development. The fix is to have one person argue each path and leave the decision to a third.

What if an old decision turns out to be wrong?

Review it as soon as one of the four criteria has changed. That's the only sensible trigger, and it comes up more often than you'd think.

Concretely: a bought-in component moves into the core because customers are asking for exactly that feature. A tool you built yourself is now available on the market as a standard, maintained and cheaper. A supplier gets acquired by a competitor.

Reversing course is uncomfortable, because it visibly corrects an earlier decision. It's still cheaper than holding on, and it gets easier if the first decision documented what conditions would require a reassessment. Then the review carries out a resolution instead of admitting a mistake.

A reversal also needs a transition. If you're replacing an in-house development, keep it running for at least one product generation, because existing customers are still working with it. If you're switching suppliers, build up the new one in parallel before you terminate the old one. Both cost a quarter and keep a sound decision from failing in execution.