The build-versus-buy decision is usually a build-and-buy decision

Build or buy is one of the oldest questions in enterprise technology and one of the worst-framed. Presented as a binary, it invites a binary answer, and binary answers to this question tend to age badly in both directions: the bought platform that cannot express how you actually work, or the bespoke system whose maintenance quietly consumes a third of your engineering capacity.

The more productive framing is narrower. Not “should we build this?” but “which part of this is genuinely ours?” Almost every enterprise capability decomposes into a commodity layer and a differentiating layer, and the two deserve opposite decisions.

Commodity is not an insult

Identity, payments, notifications, document storage, scheduling, reporting infrastructure — these are solved problems where a vendor has spent a decade and several hundred engineer-years on edge cases you have not thought of yet. Building them yourself is not ambition; it is an expensive way of learning what the vendor already knows.

The test is straightforward: if a competitor doing this better than you would not change a single customer’s mind, it is commodity. Buy it, integrate it well, and spend the attention elsewhere.

Where building earns its keep

What is worth building is the logic that encodes how your organisation actually creates value — the pricing model nobody else uses, the underwriting rules built from twenty years of your own loss experience, the workflow your operations team has refined into something genuinely faster than the market.

This is where packaged software fails most expensively, because the failure is invisible at selection time. The platform demo covers eighty percent of the process. The remaining twenty percent — the part that is actually your advantage — becomes a configuration workaround, then a customisation, then a plugin nobody can upgrade past.

Questions that produce better decisions

• If this capability were merely average, would any customer notice? If not, buy.
• How much of our real process does the platform express natively, as opposed to through configuration we would have to maintain?
• What is the upgrade story once we customise? Vendors support their product, not your fork of it.
• Where does the data live, and can we get it out in a form we could rebuild from?
• What is the total cost of the integration work, which is almost always larger than the licence and almost never in the business case?
• Who owns this in three years, when the person who chose it has moved on?

The shape that tends to hold

The durable pattern in most enterprises is a bought spine and a built edge: commodity platforms handling commodity concerns, connected by well-designed integration, with genuinely proprietary logic developed and owned in-house. It is less tidy than a single-vendor story and considerably more resilient, because it lets you replace any one component without renegotiating your entire operating model.