Why build vs buy software feels like the first decision

It arrives dressed as strategy. A gap appears - reporting is manual, the ops team is drowning, a big customer wants a portal - and the conversation jumps straight to solutions. Someone gets a quote from a development agency. Someone else books demos with three software vendors. A spreadsheet appears comparing costs, timelines and features.

It's an attractive question because it's concrete. Two options, comparable numbers, a decision a board can vote on. The prior question - what do we actually have? - is messier, so it gets skipped.

The debate that follows feels rigorous, and often is. But it's rigorous about the second question. Build vs buy is a decision about how to fill a gap - and nobody in the room has yet established what the gap actually is, or whether it needs filling from outside at all.

What's the question to ask before build vs buy?

What do we already have, what does it do, and where's the real gap?

In a business that's been running fifteen or twenty years, the honest answer to "what do we already have" is usually "nobody's entirely sure". Established businesses typically run dozens of systems, accumulated one decision at a time, by different people, for different reasons. Somewhere in that pile there's often 60% of the thing you're about to build or buy: a module nobody switched on, a feature one plan upgrade away, an integration that was never connected. We've watched a business shortlist development agencies for a system that already existed, half-configured, inside a platform they'd been paying for since 2019.

Until you know that, you can't size the gap. And the real gap is frequently smaller - or different - than the one in the business case. The reporting problem turns out to be a data problem in a system you already own. The "we need a portal" request turns out to need one workflow, not a platform.

Answering the prior question doesn't take a year. It takes an honest inventory: every system, what it does, who owns it, what it costs, and what it talks to. Most established businesses have never had one.

The three traps

Skip the prior question and the decision tends to land in one of three holes. We see all three regularly, in businesses that are otherwise well run.

Rebuilding something you could configure

The gap looks unique because nobody has looked hard at the tools already owned. So the business commissions months of custom development - and ends up with a bespoke replica of a feature that was sitting behind a settings page, a plan upgrade, or a half-day of configuration. Custom software is a serious asset when the problem justifies it. As a substitute for reading the manual, it's the most expensive one there is.

Buying overlap

The new subscription does one thing brilliantly - and four things you already pay for elsewhere. The estate gets heavier, the integrations multiply, the software bill climbs another notch, and the business now has two task managers, three document stores, and reporting in four places. Each purchase was defensible on its own. Nobody was looking at the whole.

Building to avoid a vendor conversation

Sometimes "we should build our own" really means "we're fed up with our vendor and don't want the awkward renewal conversation". That's an expensive way to avoid a phone call. If the relationship or the pricing is the problem, renegotiate it or run a proper replacement process. Don't fund a year of development out of frustration.

When does building custom software make sense?

When three things are true at once.

It's core - the process is part of how you win and keep customers, not back-office plumbing. It's a differentiator - doing it your way, rather than the standard way, is worth real money to the business. And you can own it long-term - bespoke software is an asset that needs maintaining, not a project that ends at launch. If there's no answer to "who looks after this in year three", there's no build case yet.

Building has genuinely become faster and cheaper than it was even five years ago, and that strengthens the case where those three tests pass. It does nothing to rescue the cases where they don't.

When does buying off-the-shelf software make sense?

When the job is commodity - a problem hundreds of thousands of businesses share, solved the same way everywhere. Accounting, payroll, email, document storage, standard CRM - a vendor whose entire business is that one problem will do it better, more securely, and more cheaply than anything you'd build in-house.

Buy when the need is standard, the vendor is solid, and - the test that gets skipped - it integrates cleanly with the estate you already run. A brilliant tool that doesn't talk to your other systems isn't a solution. It's a new island, and someone in your business will spend part of every week ferrying data to and from it.

Watch the whole cost, too. Per-seat pricing scales with your headcount, and integration work is rarely in the quote. The sticker price is the start of the bill, not the bill.

Make the call with the whole estate in view

A gap judged in isolation makes every option look reasonable. The same gap seen against the whole estate - what you own, what each system costs, where the overlaps already are, what's due for retirement - usually points somewhere more specific. Sometimes the answer is build. Sometimes it's buy. Quite often it's neither: consolidate two systems you already have, and the gap closes as a side effect.

That's also why the same business can be right to build one system and buy the next three. Build vs buy isn't a philosophy. It's a call you make per gap, against the estate you've actually got.

So, before the next debate kicks off in your business, three questions in order:

1. What do we already have, and what does it actually do?

2. What's the real gap, defined in business terms - not features?

3. Only then: is that gap core enough to build, or commodity enough to buy?

You can only answer the first two once you can see the whole estate: what you own, what it costs, and where the real gaps are. That's what a Discovery gives you - the prior question, answered. Build vs buy then becomes what it should have been all along: a straightforward second decision, made with the facts in view rather than blind.