Build vs Buy

Most build versus buy content compares generic advantages. Building gives you control, buying gives you speed, and so on. That is useful in theory, and almost never how the decision actually plays out inside a real firm.

In practice, few firms sit down and consciously choose between the two. They simply keep buying, upgrading or switching between similar off the shelf tools, because that feels like the safer option, right up until the workarounds needed to make each one fit have quietly become their own burden. By the time it feels like an obvious decision to build something, the cost of waiting has usually already been paid, just never on an invoice anyone noticed at the time.

This guide sets out the real signal worth watching for, why the decision is skewed against acting even when acting is clearly right, and what action actually makes sense once you recognise it, without assuming the answer is always a full custom build.

The real tell is not dissatisfaction, it is the workaround count

Firms rarely replace a tool because it fails outright. Generic software built for a wide market rarely breaks in an obvious way. It simply stops quite fitting, a little more each year, and firms adapt around it rather than noticing the fit has gone.

The signal worth watching is the slow accumulation of manual work built up around a tool to make it behave the way your firm actually needs. The extra spreadsheet that tracks what the system cannot. The exception process everyone on the team just knows, without it ever being written down. The double entry nobody questions anymore because it has been there so long it feels normal.

None of this shows up as a single complaint loud enough to trigger a decision. It shows up as a slow, steady increase in the hours it takes to do something that, on paper, the software you already pay for is supposed to handle.

Why this happens, and why it is nobody’s fault

Any tool sold to many firms at once is designed around the needs of the median customer in that market, a firm doing roughly the volume, the mix of services and the level of complexity most common across its entire customer base. That is not a criticism of the tool. It is simply how software built for a broad market has to work.

As a firm grows and starts to specialise, taking on a particular type of client, building a genuinely distinctive way of working, the distance between how the average firm in that software’s market works and how your firm actually works grows too. The tool has not got worse. Your firm has simply moved further away from the customer it was originally built to serve.

A tool built for the average firm gets a little less useful every year you spend becoming a firm that is not average anymore.

The hidden asymmetry that makes firms wait too long

A custom build has a cost you can see. It arrives as a proposal, with a number attached, that a partner has to actively approve. That visibility makes it feel like the riskier option, because it is the option anyone can point to and question.

Continuing to force fit an off the shelf tool has a cost too. It is simply paid differently, in hours, spread quietly across several people, never gathered into one place, and never arriving as an invoice that prompts a conversation. It is entirely possible for that hidden cost to grow larger than a build would ever have cost, without a single person in the firm ever seeing the total.

The cost of a custom build is the only cost that ever appears on an invoice. The cost of outgrowing a tool is paid quietly, in hours, and never sends anyone a bill.

This asymmetry is not a failure of judgement. It is a natural bias created by which cost is visible and which one is not, and it is worth naming plainly, because naming it is usually enough to correct for it.

The signals worth actually tracking

Feature comparisons rarely reveal this problem, because the tool is usually not missing an obvious feature. The signal shows up in how your team behaves around the tool, not in what the tool’s specification sheet says.

What action to take once you recognise it

Recognising the signal does not automatically mean the right answer is building everything from scratch. The right action sits on a spectrum, and the smallest one that genuinely closes the gap is almost always the correct choice.

1. Start by naming the specific step, not the whole tool. Identify exactly which part of the process the workaround exists to cover. Most firms discover the problem is one narrow step, not the entire system.
2. Check whether a small connection between existing tools closes it. Sometimes the gap sits between two systems you already use, and a lightweight piece of automation joining them is enough, with no new platform required.
3. Consider a narrow, custom built piece for that one gap alone. Where nothing existing closes it, a small, purpose built component addressing just that step, sitting alongside the tools that still work fine, is usually enough.
4. Reserve a fuller rebuild for when several processes have all outgrown their tools at once. A wholesale replacement is rarely justified by one workaround, however painful. It becomes worth considering once the pattern repeats across multiple core processes together.

The other side of the mistake, acting too early

The bias explored earlier pushes most firms towards waiting too long. It is worth being equally honest about the opposite mistake, because it is genuinely possible to act too soon.

Acting too early looks like:

• Building custom flexibility for a scale or complexity the firm has not actually reached yet
• Paying ongoing maintenance for a problem that was still mostly theoretical
• Replacing a tool that was still broadly fit for purpose, out of frustration rather than genuine mismatch

Acting at the right time looks like:

• The workaround cost has become visible, named and clearly ongoing rather than occasional
• The gap has been traced to a specific step, not a vague sense of frustration
• The likely cost of building has been genuinely weighed against the hours already being lost

The aim is not to act as early as possible, nor to wait for total certainty. It is to act at the point the hidden cost of patching has clearly overtaken the visible cost of fixing it properly, and to have the evidence from the sections above to know when that point has actually arrived.

What getting this right looks like

Firms who handle this well tend to stop treating build versus buy as a single dramatic decision made once, in a moment of crisis. It becomes an ongoing judgement, applied process by process, revisited quietly as the firm keeps growing and changing shape.

Workaround hours get noticed and named long before they become permanent fixtures nobody questions anymore. The action taken, when it comes, tends to be proportionate, the smallest change that closes the actual gap rather than an instinctive leap to replace everything at once. And the tools in place genuinely fit the shape of the firm as it actually is now, rather than the shape of an average competitor from several years ago.

That judgement is available to any firm willing to look honestly at where the hours are actually going, well before the workaround has quietly become somebody’s permanent, unofficial job.