Skip to content
← Insights

Buy, build, or integrate: choosing the right path before you spend

The most expensive technology decisions are made in the first week, when nobody's writing code yet. Here's how we help clients get them right.

The costliest technology mistakes rarely happen in the code. They happen earlier — in the decision about whether to buy a product, build something custom, or integrate what you already have. Get that call wrong and no amount of good engineering will save the project. Get it right and the build is almost anticlimactic.

Yet this decision is often made in an afternoon, on instinct, by whoever feels most strongly. Here’s the way we work through it with clients.

Start with the workflow, not the tool

The first question is never “which product?” It’s “what does the work actually need to do?” Map the real workflow — not the org chart, not the RFP — and you usually find that most requirements are common and boring, and a few are genuinely specific to how this business wins. Those few are what the decision hinges on.

When to buy

If your requirements are mostly the common, boring kind — the same problems thousands of other businesses have — buy. A mature product will do it better and cheaper than you can, and it’ll keep improving without you paying for it. Pride is the enemy here: there’s nothing clever about rebuilding a CRM.

When to build

Build when a capability is genuinely specific to how you operate, and doing it well is a real advantage. In our experience this is a smaller list than most teams first think — often half the wish list turns out to be working around the limitations of tools they already have. But when it’s real, bespoke software that fits the work exactly can be the difference between a tool people use and one they route around.

When to integrate

Frequently the honest answer is: you already own most of what you need, and the problem is that your tools don’t talk to each other. Integration is the least glamorous option and often the highest-return one — connecting what exists so it works as one system, rather than buying or building a fourth thing to sit beside the three you don’t use well.

The decision is a design, not a vote

We treat this as a piece of design work with evidence behind it — a short, honest assessment of workflow, cost over a realistic horizon, and where the genuine advantage lies. It usually takes a couple of weeks. It routinely saves clients far more than it costs, because the alternative is discovering the wrong answer six months and a large invoice later.

If you’re facing one of these decisions, it’s exactly the kind of thing we help with first — before anyone commits to building anything.