Build, buy, or connect

Why the binary misleads

Build or buy compares two ways of acquiring an application. It is a good question about applications and a poor question about operations, because most of what a growing company loses is not lost inside an application. It is lost between them: in the re-keying, the reconciling, the waiting for a handoff, the report that exists only because two systems disagree.

Framed as two options, the question forces an answer to which product replaces this — when the honest answer is often that none does, and none needs to.

There is a third option. It is usually cheaper than either of the others, and it is the one that gets skipped, because it produces nothing anybody can point at.

Three options, and what each is actually for

Buy — capability that is the same in every company

Accounting, payroll, email and calendars, e-signature, identity. You are not really buying features; you are buying somebody else's obligation to keep the thing compliant, patched and running for the next decade. That is an excellent trade for anything where your version would look identical to a competitor's.

Connect — the space between the systems

Nothing is replaced. The systems you already run exchange the facts they both need, so the same information stops being typed twice and the reconciliation stops being a meeting. This is the cheapest of the three by a wide margin and the most frequently overlooked, because at the end of it there is no new product — only work that has stopped happening.

Build — logic that is specific to how you earn money

Pricing models, approval chains, scheduling constraints, compliance records particular to your industry, the quality process a client is actually paying for. This is the part no vendor implements, because implementing it properly would mean implementing it for exactly one customer.

How to recognise commodity

• A competitor's version of it would look much the same as yours.
• There is a mature market with several credible vendors competing on price and support rather than on shape.
• Regulation, not your business, defines most of what it has to do.
• Whatever differentiates you happens around it, not inside it.

If that describes something you are considering building, buy it — and then resist customising it heavily. Deep customisation of a bought product quietly converts a maintained system into an unmaintained one, and you find out at the next upgrade.

How to recognise connective work

• The same fact is entered in two places by a person.
• A human being is the integration layer, and their calendar shows it.
• A report exists mainly to explain why two systems disagree.
• The delay in a process is almost entirely waiting for a handoff rather than doing the work.

If the cost is re-typing between systems, integration removes it without replacing anything. That is worth stating plainly, because it is the answer that sells least and applies most often — and it is why keeping the systems that earn their place is a starting position for us rather than a concession.

How to recognise genuinely differentiating logic

• You could describe the rule to a competitor and it would not help them, because it is a consequence of how you specifically operate.
• It changes when the business changes, and at the moment it lives in somebody's head.
• You have customised a bought product far enough that upgrades have become frightening.
• The process is the commercial model: how you price, how you guarantee, how you allocate people to work.

This is the part worth building, and frequently the only part. What that looks like in practice is the subject of its own page.

The four ways this goes wrong

Buying what differentiates you

You adopt the vendor's process, discover the gaps, and fill them with spreadsheets. Six months later those spreadsheets are load-bearing, and the product you bought is the thing they work around.

Building what is commodity

You now own an accounting system. The build was the cheap part; year four is the expensive part, and none of it makes you better at what you actually sell.

Connecting what should have been replaced

Integration is very good at preserving things. If the underlying process is broken, connecting it makes the breakage faster, more reliable and considerably harder to argue with.

Automating a process nobody has examined

Automation is a multiplier, and it multiplies whatever is there. A process that has never been questioned is the wrong thing to multiply.

The answer changes as you grow

Early on, buy almost everything. At twenty people one spreadsheet in the middle of the operation is not a risk, it is a reasonable use of a good tool, and building anything is a distraction from finding out what the business is.

Somewhere between forty and a couple of hundred people, the connective layer becomes the dominant cost. Nothing individually is broken; the gaps between things are. This is the stage at which connecting produces more relief per pound than either buying or building, and it is the stage at which most companies instead go shopping for another product.

Later, some part of the operation has become the business itself — the way you price, deliver or guarantee is now the thing clients choose you for. That part is worth building, and only that part.

The uncomfortable implication is that a decision that was correct three years ago is probably wrong now, and nothing in your stack will tell you.

A decision procedure

In order. Most of these can be answered in a week, and the first one usually changes the shape of the rest.

1. 01What is the cost, in hours or in delayed decisions, and where exactly does it occur? If it cannot be located, the problem is not yet understood well enough to spend money on.
2. 02Is that cost inside a system, or between systems? Between is the common answer, and it points at connecting.
3. 03Does a mature product fit the process as it should be — not as it currently is? Buying to fit a process nobody has examined is how you buy the wrong product.
4. 04Would connecting what you already run remove enough of the cost that the rest can wait a year?
5. 05Is what remains specific to how you compete, or is it just unfamiliar?
6. 06Will it still be right in three years, or is the process still moving? Encode the stable things.
7. 07What does another year of doing nothing actually cost? Sometimes very little, and that is a legitimate answer.