A Practical Framework for Build-vs-Integrate Decisions

The Question Behind the Question

'Should we build this or buy it?' is usually asked too late, after a vendor demo or an internal proposal has already framed the answer. The more useful question underneath it is about ownership: which system should be the source of truth for this data or capability, and what does it cost — in engineering time and in flexibility — to make that true.

Treating build-vs-integrate as a procurement decision instead of an architecture decision is why so many systems end up with three different sources of truth for the same entity, each maintained by a different team that stopped talking to the others.

Three Questions Before the Vendor Comparison

Is this capability core to what makes the business different, or is it a solved problem everyone needs? Core, differentiating capability is worth owning. A solved problem — authentication, payments, email delivery — is rarely worth rebuilding, no matter how tempting the customization looks in year one.

How often does this need to change, and who needs to be able to change it? A workflow that product or operations needs to adjust weekly belongs in something your team controls directly. A capability that changes on a vendor's release cycle is a fine candidate to integrate.

What does the exit cost look like? Every integration is a dependency. The real cost isn't the initial contract — it's what happens years later when the vendor's roadmap diverges from what the business needs and migrating away means untangling years of accumulated integration points.

The Middle Ground Gets Ignored

Most real decisions aren't a clean build-or-buy binary. The more common — and more often ignored — option is to integrate a capability but own the interface to it: build a thin internal layer that talks to the vendor, rather than letting every part of the codebase call the vendor's API directly. That single decision often determines whether a future vendor switch takes a week or a quarter.

Data Ownership Comes First

Before any build-vs-integrate decision, the data ownership question has to be settled: which system is authoritative for a given entity — a customer record, an order, an inventory count. Every integration should have an explicit, written answer to 'who wins if these two systems disagree,' decided in advance rather than discovered during an incident.

Applying It

In practice, this framework produces a short, explicit document for any meaningful system boundary: what's being built versus integrated, who owns the data, what the interface layer looks like, and what the estimated exit cost is if the decision needs to be reversed. That document is worth more than the decision itself, because the reasoning behind a boundary is what future engineers need — the code only tells them what was decided, not why.