Build versus buy for internal platforms

The build-versus-buy conversation almost always begins in the wrong place. Somebody produces a comparison: the product costs this much per user per year, the build costs this much in developer time, here is the payback period. It is a tidy analysis and it is close to worthless, because both numbers are the two things about the decision that are easiest to estimate and least likely to determine the outcome.

What actually determines whether the decision was right is discovered in year three, and it turns on questions nobody asked in year zero.

The comparison that is usually being made is not honest

Two systematic distortions creep into almost every one of these analyses, and they push in opposite directions, which is why the conclusion is unreliable rather than merely wrong.

The build is costed as a project and the product is costed as a licence. The build estimate includes development and stops there. The product estimate includes the subscription and stops there. But a bought product requires configuration, integration, data migration, user administration, training, and somebody to own the vendor relationship — and a built system requires hosting, monitoring, security patching, and somebody to maintain it. The comparison is only meaningful if both sides are costed on the same basis, over the same horizon, including the operational work. They almost never are.

The build is compared against the product's marketing, not the product. The demonstration shows the product doing what your process needs. It does not show the six things your process needs that the product does not do, because you will not discover those until implementation. Every enterprise product implementation involves a negotiation between the product's model of the world and yours, and the currency of that negotiation is either customisation cost or process change, both of which are absent from the business case.

The question that actually matters

Ask this instead: in three years, when the business has changed, which of these options can I still do something about?

This reframes the decision around optionality, and optionality is what you are really buying or forfeiting. It is also the thing you cannot buy back later at any price.

With a bought product, the option to change is bounded by what the vendor permits. If your process needs to do something the product does not model, you have three choices: change your process to fit, pay for customisation that you will then have to maintain across upgrades, or build something alongside it and integrate — which quietly reintroduces the build you were trying to avoid, in the least favourable form.

With a built system, the option to change is bounded by the capability of the team that owns it. If that team exists and is competent, the option is real. If it does not — if the system was built by a supplier and handed over to a business function with no engineering capacity — then the option is theoretical, and you have taken on the cost of a build with the inflexibility of a product.

Where the answer is clearly "buy"

The process is not differentiating and it is genuinely standard. Payroll, expense management, ticketing, HR records, accounting. These processes are similar enough across organizations that a product encodes a great deal of accumulated wisdom about them, and your organization's variations are almost certainly accidental rather than valuable. Buy, and change your process to match.

The domain is regulated and the rules change. Tax calculation, statutory reporting, compliance monitoring. A vendor amortises the cost of tracking regulatory change across every customer; you would carry it alone, and you would carry it forever.

You have no engineering capacity to maintain what you build. This is the decisive one and it is the one organizations most consistently lie to themselves about. A bespoke system with no owner will decay, and a decayed bespoke system is far worse than a constraining product, because at least the product has a vendor keeping it alive.

Where the answer is clearly "build"

The process is how you compete. If the way you route work, price a job, or schedule a fleet is a source of advantage, encoding it in a product that your competitors also use is an odd thing to do deliberately. Buying commoditises the thing that differentiates you.

The system's job is to sit between other systems. Integration-heavy internal platforms are usually a poor fit for products, because a product's connectors are excellent for what the vendor anticipated and awkward for what they did not. The core of the work is reconciling systems with incompatible models, and fighting a connector abstraction while doing it is a tax you pay forever.

The guarantees are unusual. When the system must lose nothing under failure, reconcile exactly, retry without duplicating, or produce an auditable record of every decision, you need control over state and transaction semantics that products abstract away. You will not get it back through configuration.

What you need is small and specific. A great deal of enterprise buying is a large product acquired to obtain one capability, whose remaining ninety per cent becomes an administrative burden. A focused internal tool that does exactly one thing well is frequently cheaper to build than the chosen product is to configure, and dramatically cheaper to own.

The middle path, and its trap

Most real decisions land in the middle: buy the platform, build the parts it does not cover. This is often correct and it contains a specific trap that is worth naming.

The trap is that the built parts accumulate against the boundary of the bought thing, and over time the organization ends up maintaining a substantial bespoke system whose data model is dictated by a product it no longer especially wants. Every extension is harder than the last, because each must be reconciled with a model you do not control and cannot change.

The defence is to be deliberate about the boundary. Decide which system owns which data. Keep the extensions on your side of the line, talking to the product through a documented interface rather than reaching into its internals or its database. That discipline costs something up front and it is what preserves the option to replace the product later without rewriting everything you built around it.

Price the exit, always

Whatever the decision, cost the exit before making it. Not because you plan to leave, but because the answer is diagnostic.

If leaving a product means reconstructing your business rules from a visual configuration nobody documented, that is a legacy modernization problem you have chosen to schedule for five years from now, and it belongs in the business case today.

If leaving a built system means nothing, because it is written in a mainstream stack with documented interfaces and your team can hire for it, that flexibility is real value and it should be counted as such.

The organizations that get this decision right are not the ones with better spreadsheets. They are the ones that were honest about which capability they actually have, and about what it would cost to change their mind.