Skip to content

Decision guide · Build vs. buy

The build option always looks cheaper before anyone owns it.

Every capability gap has three real answers-buy, configure an existing platform, or build custom-and each carries a different bill long after launch.

The answer often depends on who is in the room.

A developer asked to close a capability gap will usually propose building it. A vendor asked the same question will usually propose buying it. Neither answer is wrong on its face, and neither is a decision-both are defaults from where each person sits.

A useful decision starts somewhere else: is this capability genuinely differentiating, or is it a solved problem the organization is about to solve again from scratch? Undifferentiated plumbing-scheduling, ticketing, basic reporting-rarely earns the ongoing cost of ownership that a build creates.

The build estimate that gets presented to leadership is almost always the cost to ship version one. It is rarely the cost to secure, patch, extend, and eventually replace it once the person who built it has moved on.

Boundary

This is a decision lens, not a software development, procurement, or contract-negotiation engagement.

Ownership lenses

Six questions before a developer starts typing.

  • DifferentiationDoes this create a real advantage, or is it plumbing every competitor also needs?
  • Total ownership costThe build estimate is a down payment. What does patching, hosting, and support cost every year after?
  • Time to valueCan the organization wait for a build, or does the business need this working sooner than that?
  • Change velocityHow often must this adapt, and can a vendor's roadmap plausibly keep pace with that rate of change?
  • Exit and portabilityIf this choice is wrong, what does reversing it cost-in either direction?
  • Internal capabilityDoes the organization have the ongoing capacity to operate what it builds, not only the capacity to build it once?

Working process

Price the whole window, not the first invoice.

  1. Name the capability and its claim

    State plainly what differentiation, if any, this capability is supposed to create.

  2. Price the full ownership window

    Build, buy, and configure options each get a build-or-license cost and a multi-year operating cost.

  3. Test the exit

    For each option, state what reversing the decision requires in data, retraining, and disruption.

  4. Decide and set the review trigger

    Record the choice, the accepted trade-off, and the condition that would justify revisiting it.

If buy wins, the vendor-selection lens applies next

Hypothetical pattern

A scheduling tool only one developer can touch

A team built a small internal scheduling tool years ago to avoid a subscription fee. It works, but only one person understands it, nobody documented the last three changes, and that person is now the organization's single point of failure for a process the whole team depends on. The cheap build was never free-it deferred its real cost onto whoever has to maintain it.

See how that concentration gets priced

Next step

Bring the capability gap everyone assumes means "build."

A focused brief can turn a default answer into a priced comparison with an owner attached.