Build and buy are not identities. They are choices about ownership, constraint and reversibility—and most useful answers sit somewhere between them.
There are more than two choices
The usual debate creates an artificial binary: accept the limitations of a product or carry the burden of custom software. In practice, organisations have a wider set of moves. They can buy, configure, integrate, extend, build a narrow layer, replace one component or decide that no system change is justified yet.
The goal is not to win an argument for custom development. It is to place ownership where it creates the most value and keep commodity work outside the organisation where possible.
- Buy when the problem is standard and the operating model can adapt without losing what matters.
- Configure when the product is sound but terminology, permissions or workflows need adjustment.
- Integrate when the value sits in connecting systems rather than replacing them.
- Build when the workflow creates real differentiation or requires control a vendor cannot provide.
- Wait when the process, ownership or demand is still too unstable to encode.
Compare total constraint, not purchase price
A subscription price is not the cost of buying. The real cost includes configuration, integration, workarounds, training, duplicated data, vendor dependence and the effort required to leave later.
The development estimate is not the cost of building either. Custom software creates an enduring responsibility: product decisions, security, maintenance, support, documentation and adaptation as the organisation changes.
A useful comparison asks which option creates the most tolerable set of constraints over time. Cheap software that bends the organisation around it can be expensive. A custom build that recreates a solved problem can be equally wasteful.
Six tests for the decision
The answer becomes clearer when the team evaluates the decision against the same criteria rather than arguing from instinct. None of these tests decides the answer alone; together they show where ownership matters.
- Differentiation — does this capability change why a customer chooses or trusts us?
- Process stability — do we understand the workflow well enough to encode it?
- Integration density — how much value depends on connecting existing systems and data?
- Control and risk — what must we govern directly because of security, compliance or continuity?
- Internal capability — who will own decisions and maintenance after launch?
- Reversibility — how difficult will it be to change direction when assumptions move?
A sensible default
Buy the commodity. Configure the common. Integrate before replacing. Build the differentiating layer. Keep every decision reversible until the evidence justifies deeper commitment.
This default is intentionally conservative. Custom software earns its place when it expresses something important about how the organisation creates value—not simply because an off-the-shelf product feels inelegant.