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

Why isn't a cost comparison enough?

Because it compares a snapshot and ignores the question of capability. Two examples show the limit.

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

Second scenario: a machine builder develops its own operating software because the in-house electronics team has capacity. The comparison only counts development hours. Not counted: ten years of maintenance, training, security updates, and the people permanently tied up with 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 that lasts 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 trial run, not a permanent decision.

Which four criteria matter beyond price?

Put them side by side in a table and the decision becomes traceable, even when it goes against the math.

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 costs. 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 span. A piece of software or a custom component stays with you for ten years. Maintenance costs a share of development 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.
• Missed alternatives. The people doing the development aren't working on something else. This item appears in no calculation, and when development capacity is tight, it's the biggest one.
• Ramp-up time to maturity. The first version isn't the one you take to market. Two iterations are normal.

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

Buying has its own items that don't show up in the price. Integration into your processes, dependence on the supplier's schedule, the effort for incoming quality control, and the question of who is liable to the customer when the purchased part fails. With software, add interface maintenance and version changes. 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 have 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 without building up staff for it. Sales access 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 they take on your competitor, or if their priorities shift? These three cases belong in the contract before the first project starts.

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

How do you decide as a leadership team?

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

What works well is a single page with five points: the task, both options with five-year costs, the four criteria from the table with an assessment, the recommendation, and the question of what condition would trigger a fresh look at the decision. 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 makes sense a year later.

Watch out for one pattern that shows up again and again: 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 for each option and leave the decision to a third.

What do you do when 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.

For example: 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 product, 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 you wrote down at the time of the first decision what condition would call for a fresh look. Then the review is simply carrying out a resolution instead of admitting a mistake.

A reversal also needs a transition. If you're retiring an in-house development, keep it running for at least one product generation, because existing customers still rely on it. If you're replacing a supplier, ramp up the new one in parallel before you terminate the old contract. Either move costs you a quarter and keeps a sound decision from failing in execution.