The build vs. buy conversation usually starts in the wrong place. An engineer says "we could build this ourselves in three months." A vendor quotes twelve months of contract and a per-seat model that doesn't fit how you work. Leadership instinctively wants to avoid lock-in.
None of this is the question. The question is: what is the strategic value of owning this capability yourself?
When the answer is "not much" — which it usually is — you should buy.
The case for buying (most things)
The default should be to buy. Here's the honest reasoning:
Most of the software you need to run a business exists off the shelf, built by companies whose entire product focus is that specific problem. Your CRM, your payments stack, your communication tools, your analytics platform, your HR system. The probability that you'll build something materially better than the leading vendor in any of these categories is very low. And even if you somehow could, the cost of running it over years compounds in ways that aren't obvious at the start.
The honest calculation is: what is your engineering team's time actually worth, and what is the best use of it? Building an internal scheduling system, or building the thing that actually differentiates your product in the market?
The case for building (rarely)
There are real cases where building makes sense. They're fewer than most engineering teams believe, but they're real:
- The use case is your competitive differentiation. If your core value proposition is a recommendation engine, you can't outsource the recommendation engine. The IP matters. The data flywheel matters. The iteration speed matters. You need to own it.
- The use case requires proprietary data in a way no vendor can replicate. Your operational data is unique. Sometimes the model you train on that data — for demand forecasting, pricing, or operations — is worth building and owning.
- The vendor genuinely can't do what you need, and customisation cost exceeds build cost. This is rare, but it does happen — especially for complex multi-market operations with specific regulatory or operational requirements.
The hidden costs on both sides
Build side: initial development is never the real cost. It's the maintenance, the team you need to run it, the tech debt it creates, the upgrades you have to fund yourself, and the opportunity cost of what your team didn't build instead. Software you build is software you own forever — including all the problems.
Buy side: integration time is real and usually underestimated. Vendor lock-in is real, though often overstated — most enterprise tools have migration paths. Seat-based pricing can become expensive at scale. And the gap between what was demoed and what the product actually does in your specific context is a consistent source of disappointment. Pilot the tool before you sign the contract.
The question that reframes it
Before you start the build vs. buy evaluation, ask one question: what is the most important thing our engineering team could be building right now?
If the answer is "the CRM replacement," you have a bigger problem than CRM selection. If the answer is something specific to your product — a capability no vendor has, a data model that reflects your business uniquely — then the CRM question answers itself. Buy something, move on, and spend the energy on the thing that's actually yours to own.
Most organisations spend more time evaluating the wrong decision than it would have taken to just move forward. The discipline to recognise commodity infrastructure and stop debating it is a competitive advantage in itself.