Build Versus Buy: A Decision Framework That Survives Contact With Reality

The build-or-buy conversation tends to be conducted as a cost comparison. Licence fees on one side, engineering days on the other, and whichever number is smaller wins. It is a tidy way to reach a decision and it routinely produces the wrong one, because the numbers being compared are not comparable and the largest costs appear on neither side of the ledger.

A more useful framing starts somewhere else entirely: which parts of this problem are actually specific to your organisation?

Differentiation is the real axis

Every system decomposes into capabilities. Some of them are how you compete — the pricing logic, the underwriting model, the particular workflow that makes your operations team faster than your competitors'. Others are table stakes that every organisation in your position needs and none of them wins on: authentication, payment processing, sending email, storing files.

Building a table-stakes capability is spending scarce engineering attention on something that can only ever reach parity. Buying a differentiating capability is more insidious: you inherit the vendor's model of how the work should be done, and your process converges on your competitors' because you all bought the same product.

This is why the cost comparison misleads. A cheap build of something undifferentiated is still a bad trade, and an expensive build of the thing you compete on may be the best money you spend.

The test we find most useful: if this capability were twice as good as everyone else's, would a customer notice or care? If yes, it is a candidate to build. If no, buy it and spend the attention elsewhere.

The integration cost that nobody quotes

Buying is systematically under-costed because the licence fee is visible and everything else is not.

What is not in the quote: the integration work, which for anything touching your core data model is rarely trivial. The data migration. The mapping between the vendor's concepts and yours, which is where most of the pain lives — their notion of a "customer" will not be yours, and reconciling that is design work, not configuration. The training. The ongoing effort of staying current with their releases. The workarounds for the three things it does not quite do, which will be built in spreadsheets and scripts and will become load-bearing.

A reasonable planning assumption for a substantial enterprise product is that first-year total cost lands at two to four times the licence fee. That is not a criticism of vendors; it is the nature of fitting general software to a specific organisation. It simply belongs in the comparison.

Building has its own hidden line, and it is the one teams consistently forget: the software does not stop needing attention when it ships. Someone maintains it, patches its dependencies, answers questions about it, and eventually rewrites the part that has become unbearable. Budgeting a build at its delivery cost and comparing that to a recurring licence fee is comparing a one-off number to an annual one.

Ask what happens when it does not fit

The scenario worth testing is not the happy path. It is the moment eighteen months in when the business needs something the product does not do.

With software you own, that is a prioritisation conversation. It might be expensive, it might be deferred, but the path exists and you control it.

With a bought product you have four options, all worse. Persuade the vendor to build it, on their timeline and their judgement of whether other customers want it. Work around it outside the system, which is how shadow spreadsheets are born. Change your process to match the software. Or replace the product, at a cost that has grown with every month of accumulated data and integration.

This asymmetry is the strongest argument for building the parts of a system where your requirements are unusual or actively changing. It is also the strongest argument for buying where your requirements are ordinary and stable — because there you will never need the flexibility you would be paying for.

The answer is usually neither, or both

Framed as a binary, build-or-buy forces a choice that the system itself does not require. Most well-designed architectures do both, deliberately.

Buy the payment processor and build the pricing logic that sits on top of it. Buy the identity provider and build the permission model that reflects how your organisation actually delegates authority. Buy the warehouse and build the transformations that encode your definitions.

The pattern is consistent: buy the infrastructure, build the logic that makes it yours. The boundary between those layers is where your architecture earns its keep, and getting it in the right place matters more than either purchasing decision.

Practical questions worth asking

Before committing either way, these tend to surface the real answer faster than a spreadsheet does.

• What happens to our data if we leave? Ask for the export format specifically, and ask to see one. "We provide a full export" covers everything from a documented API to a CSV missing your relationships.
• Who has done this integration before? Ask the vendor for a reference customer with a comparable stack. Vague answers here predict a difficult implementation.
• What is our second-year cost? Including support tier, the seats you will actually need rather than the ones you are estimating, and the modules that turn out to be separately licensed.
• If we build it, who maintains it in three years? If the answer is one enthusiastic engineer, you have a risk rather than a plan.
• What is the smallest version that would tell us? Frequently you can trial a bought product against a real workflow, or build a narrow slice, for a fraction of the committed cost. Buying information is cheaper than buying a decision.

A note on timing

Early-stage organisations should lean toward buying nearly everything, because their scarcest resource is attention and their requirements are not yet known well enough to encode. The differentiating capability is often not the software at all.

As an organisation matures, the calculus shifts. Requirements become specific, volume makes per-seat pricing painful, and the parts of the process that genuinely differentiate become clear. This is the point at which selectively bringing capability in-house starts to pay — and the point at which many organisations instead sign a larger contract, because switching has become expensive.

Which is the argument for making the boundary decision consciously and early, even when the answer is to buy. Buying with a clear view of what you would eventually want to own produces a very different integration design than buying because it was the faster option this quarter.