openskills.info
Course Preview

Build Versus Buy Decisions

A build-versus-buy decision compares creating and operating a capability in-house with adopting a product, service, open-source component, or hybrid. The comparison tests fit, whole-life cost, delivery time, control, risk, and the cost of changing direction later.

itEngineering leadership and delivery management

Don't Panic — Build Versus Buy Decisions

A build-versus-buy decision is an argument about how to obtain a capability, wearing enough arithmetic to be allowed into a budget meeting. Build means creating and operating most of the solution. Buy means adopting somebody else's product or service. The useful choices also include reuse, managed open source, outsourcing, and hybrids, because reality has an unhelpful resistance to binary menus.

Begin with the outcome. "Replace the CRM" is not an outcome; it is the current answer asking to be reincarnated. State what a user or service needs, how success is measured, and which constraints really disqualify an option. Keep the current arrangement as a do-nothing baseline, since doing nothing still has costs and risks, even when its project plan is impressively short.

Then split the capability into components. Commodity identity, shared workflow, distinctive decision logic, and reporting do not need the same source. This is where hybrid stops meaning indecision and starts meaning a boundary: buy the mature component, build the part that carries unique policy or customer value, and own the integration between them.

Compare equivalent things. Build cost includes discovery, delivery, operation, maintenance, security, replacement, and the work the team cannot do instead. Buy cost includes evaluation, fees, configuration, integration, internal support, renewal, and exit. A subscription without integration is a brochure. A build estimate without maintenance is a prototype applying for a permanent job.

The numbers arrive as ranges because the future has declined to provide an invoice. Sensitivity analysis changes important assumptions and shows which ones can reverse the ranking. Find the break-even value for volume, delay, maintenance, price growth, or migration effort. The assumption nearest that point deserves monitoring after the decision; the others may continue their peaceful existence in the appendix.

Replace confident claims with a small, difficult trial. Use representative data. Exercise identity, export, accessibility, performance, deployment, or recovery where those conditions matter. Agree on acceptance criteria and a stop date first, so the trial gathers evidence instead of quietly becoming production.

Finally, write an architecture decision record, a short account of context, options, evidence, tradeoffs, consequences, ownership, and review triggers. Buying does not remove ownership. It moves ownership toward integration, supplier, contract, data, renewal, and exit. Building keeps product, operations, security, maintenance, and retirement close to home. Open source brings its own luggage.

Read the Intro for the complete mental model, the Cheatsheet for criteria and cost lines, and the Practice Reference when a real decision needs structure. The Exercise supplies a fictional case where the arithmetic can be checked without spending anyone's actual procurement budget. The durable answer is not build or buy. It is a supported choice with a known way back.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources