Most build-or-buy conversations start with a price comparison and end badly. A subscription looks cheaper than an engineering team, so the business buys — and eighteen months later it is running four tools that do not talk to each other, paying per seat for all of them, and shaping its operations around what the software permits.
The cost comparison is not wrong. It is just answering a smaller question than the one being asked.
Ask what the thing is to you
The useful split is not cost. It is whether the capability is something your customers experience as you.
Payroll is not. Nobody chooses a supplier because of how their payroll runs. Buy it, integrate it, forget it. But the thing your customer touches — how they check out, how their order is tracked, how a claim gets assessed — is a place where being identical to your competitors is a strategic cost, not a saving.
If a capability is how you differ, and you buy it off the shelf, you have bought the same differentiation everyone else can buy.
The questions that actually decide it
Would a competitor be able to tell what we do from the outside? If yes, that is a build candidate. If they could not care less, buy it.
How often does this need to change? Tools are excellent at stable problems and painful at moving ones. If the process changes quarterly because the market does, configuration will run out before the change does.
What happens when the vendor changes their mind? Pricing, roadmap, an acquisition. If a decision made in another company can break yours, you have taken on a risk that does not appear in the price.
Usually the answer is both
In practice the right shape is rarely all of one. Buy the commodity layers, build the thin part that is genuinely yours, and spend the engineering budget on the seam between them — because the integration is where most of the value and nearly all of the pain lives.
That is also the honest version of what a consultancy should tell you. If the answer is buy, the useful thing we can do is say so and help you wire it in properly.