Should we buy off-the-shelf software or build our own?

Short answer: buy or configure when you need it running in weeks, the problem is common, and a good-enough answer fast wins the business case. Build where accuracy, explainability or audit requirements demand control a product can't give you. Most projects are a blend: configure a platform for the fast 80%, build only the rest.

It's the question I hear most often at the start of a project, and I don't have a favourite answer. I have a decision tree. The useful work isn't picking a side — it's working out which parts of your problem belong on which side.

Buy, or configure a platform, when…

You need it running in weeks, not quarters. A product you configure is almost always faster to a first result than anything you build.
The problem is common and well understood. A chat assistant over your own documents, or a Copilot rollout, are problems many teams have already solved.
You don't need to control every detail of how it behaves. If "roughly right, and consistent with the vendor's roadmap" is acceptable, you don't need to own the internals.
A good-enough answer, fast, wins the business case. Sometimes speed to value matters more than precision.

Build, when…

Accuracy and determinism are non-negotiable. The same question has to give the same answer every time.
You have to prove, line by line, why the system answered the way it did. Explainability you can't configure into a black box.
The workflow is specific enough that no product fits without heavy compromise.
Regulatory or audit requirements force a level of control you can't get from someone else's product.

Most projects are a blend

In practice the answer is rarely all one or the other. Configure a platform for the fast, common 80%, and build custom only where precision, explainability or compliance demand it. The boundary between the two is a design decision in its own right, and worth making on purpose rather than by default.

The expensive mistake goes both ways

Building what you could have bought burns months you didn't need to spend. Buying what you needed to build leaves you stuck later — usually at the moment an auditor, a customer or your own team asks a question the product can't answer.

That's why it's worth mapping before you commit a budget: which parts are commodity, which parts are where your requirements are unusual, and what each side will cost to own.