How To Decide Whether To Build Or Buy

Should You Build It Or Buy It?

Ask whether the function differentiates you. Not whether it is complicated, not whether a tool exists, not what the licence costs.

Fowler splits software into strategic, where the function is a competitive advantage, and utility, where it is necessary but undifferentiating. For a utility function, he says, you buy the package and adjust your business process to match the software. For strategic functions custom software is essential, since you do not want the same software as your competitors.

Then, before you total anything up, read Brandon Byars on the second half: you cannot buy integration.

The Risks Are Not Symmetrical

This is the part of Fowler's argument that changes how you should run the project, and it is easy to skip.

On a utility project, he writes, the biggest risk is some kind of catastrophic error. You do not want the sewage pipe to break or to miss payroll. So you need enough attention to make sure that does not happen, and other than that you want costs to be as low as possible.

On a strategic project the biggest risk is not doing something before your competitors do. So you need to be able to react quickly, and cost is much less of an issue, because the opportunity cost of not doing something is far greater than the costs of software development itself.

Read those side by side and, on my reading, they describe two projects that should be judged differently. On a utility project I would treat cost and reliability as the measures. On a strategic project I would treat speed as the measure, since that is the risk Fowler names.

In my experience the most expensive mistake here is not picking wrong. It is picking correctly and then running the project as though it were the other kind.

You Cannot Buy Integration

Brandon Byars, writing in 2021, makes a point I have rarely seen in a build or buy calculation.

Despite a wide range of tools that aim to simplify wiring systems together, he writes, you cannot buy integration. When you buy an integration product, you are agreeing to build the integration itself in a commercial programming language.

He is blunt about where the cost lands. The lines between systems, he writes, are the hidden and often primary driver of organisational tech debt, and the reason that things just take longer now than they used to.

Note the exact scope of that. Byars is writing about integration products, the tools sold to wire systems together, not about every package on the market.

My own extension of it, which he does not make, is that the same logic applies whenever a bought thing has to talk to something you already run. Buying removes the cost of building the feature. It does not by itself remove the work of connecting it. In the business cases I have read, the build column carries that work and the buy column often does not.

What Byars Recommends Instead

His argument does not stop at the diagnosis, and the recommendation is worth reading because it inverts the usual buy logic.

Byars contends that integration products are not in the same category as fraud detection products or analytics products or CRMs, because they do not directly solve a business problem. They are programming languages, bundled with a toolchain and a runtime. He argues that every mandate to use low code tools for all integration accrues significant accidental complexity, and that putting the tool at the centre of an architecture diagram treats integration as a tactical concern rather than an interface one.

His recommendation is that the principles behind a modern view of integration are best managed with a general purpose language, which reorients commercial integration tools towards simplifying tactical implementation concerns.

Read that against Fowler's rule, quoted at the top of this piece, and my own reading is that the two line up. Fowler puts what differentiates you in the build column. Byars puts the interfaces between your systems in a general purpose language, which is the same instinct applied to the wiring. That is my joining of them rather than a claim either makes.

My own view is that this is the most useful correction to a build or buy business case, because it does not change the test, it changes what goes in the columns. The question of whether the function differentiates you is unaffected. What changes is the estimate underneath it.

The Categories Move

Fowler is explicit that this is not a static dichotomy. Business activities that are strategic can become a utility as time passes, and less often a utility can become strategic if a company figures out how to make that activity a differentiator.

That matters for a decision you are making today in two ways.

Something you built as a differentiator five years ago may not be one now. My own view is that the cost worth questioning then is not the software itself but the effort still being spent treating it as strategic. And something everyone buys today can become a differentiator if you find a way to make it one, which is the rarer case but the more valuable.

The test is therefore worth re-running on existing systems, not only on new ones.

Example: Payroll And Quoting At The Same Distributor

This is a constructed example, not a client engagement. It is assembled from the two tests above.

A distributor is deciding about two systems in the same quarter.

The first is payroll. Nobody has ever chosen this distributor over a competitor because of how it runs payroll. On Fowler's test that is a utility function, so the answer is to buy a package and adjust the process to fit it. Fowler names catastrophic error as the risk to manage there. What I would do with that, which he does not prescribe, is select on reliability and cost and resist customisation.

The second is how it quotes for part orders. Its quoting logic reflects trade relationships and stock positions that competitors do not have, and customers say so. On the same test that is strategic, so the answer is custom, and the project is run for speed rather than for cost.

The interesting part is what they share. Both need to talk to the finance system and to the stock system. Byars writes about integration products rather than payroll packages, so he does not settle what any particular licence covers. My own reading is that the connecting work has to be established either way, which is why I would put a line for it in both projects before comparing them.

That is my reading of how the two sources combine on a single case. Fowler settles which to build. Byars is the reason I put an integration line on both columns.

Signs A Build Or Buy Call Is Being Made On The Wrong Test

Five signals.

1. Your business case compares build cost against licence cost, with no integration line on the buy side.
2. Nobody can name the customer facing reason the function differentiates you, but the plan is still to build.
3. You are customising a bought package heavily, which suggests the function may be strategic after all.
4. You are maintaining custom software for a function no customer has mentioned in years.
5. The decision is being made on which option is cheaper this year.

Signal three is the one worth pausing on. Heavy customisation of a package is Fowler's utility answer being applied to something the business is treating as strategic. In my experience that cost arrives gradually rather than at once, which is why it survives so long unexamined.

If any of those apply, you can Request The Free Scoping Audit. The What We Build and Agentic AI sections are on the main site.

Common Questions About Build Or Buy

What Is The Build Versus Buy Test?

Martin Fowler's version is a single question: is the business function a differentiator. If the process you are supporting is part of your competitive advantage, build custom software. If it is not, buy a package and adjust your business process to fit the way the package works.

What Is Utility Versus Strategic Software?

Fowler's terms for the two sides of that test. Utility functions are necessary but undifferentiating, so you buy and adapt. Strategic functions are competitive advantages, where custom software is essential because you do not want the same software as your competitors.

Why Does Buying Not Remove The Integration Cost?

Brandon Byars puts it directly: you cannot buy integration. When you buy an integration product, you are agreeing to build the integration itself in a commercial programming language. He is writing about integration products specifically. Extending that to any bought package that must connect to your systems is my own reading.

Should Build Or Buy Projects Be Run Differently?

Fowler says the risks differ. On utility projects the biggest risk is a catastrophic error, so keep costs low while preventing failure. On strategic projects the biggest risk is not moving before competitors, so react quickly and treat cost as secondary to the opportunity cost of delay.

Can A Decision Change Later?

Yes. Fowler is explicit that this is not a static dichotomy. Strategic activities can become utilities as time passes, and less often a utility becomes strategic if a company finds a way to make it a differentiator. The test is worth re-running on systems you already own.

Part of The Development Guide. See also Systems Integration, Web Applications and Which Steps Actually Deserve AI Workflow Automation.