Build vs. Buy: A Working Decision Framework

Two variables determine the build-versus-buy decision: whether the capability differentiates the business, and whether its requirements are stable. Everything else is cost accounting, and both paths are routinely presented with major costs omitted.

The evaluation is harder than it was five years ago because vertical SaaS has expanded faster than the methods for assessing it. Most industry problems now have several dedicated platforms. Some are strong. More are partial solutions that present as complete in a demo and reveal their boundaries after signature.

Variable 1: Differentiator or commodity

Buy commodities. Build differentiators. The classification is usually obvious and is worth stating explicitly because organizations build commodities more often than they buy differentiators.

Commodity means every organization performs the function approximately the same way and no competitive advantage derives from the difference. Payroll, general ledger, email, HR records, expense reporting. A vendor serving hundreds of organizations has encountered edge cases the internal team has not considered, and buying acquires that accumulated handling.

Differentiator means the capability is how the business competes or how it uniquely operates. The pricing engine, the workflow reflecting the specific operating model, the integration logic joining systems in a configuration no vendor anticipated. Constraining a differentiator to a vendor's model constrains the business to the vendor's model.

Variable 2: Requirement stability

Stable, well-understood requirements favor buying. Requirements still being discovered favor building.

The reasoning is about the cost of change rather than the cost of construction. A vendor platform sets what can change and how quickly. When the internal process diverges from the vendor's model, the organization pays in workarounds, in customization that complicates every upgrade, or in changing its process to match the software.

If the process is still being defined, that divergence is not a risk — it is the expected state, occurring repeatedly.

Costs omitted from the buy case

Vendor pricing is a fraction of total cost.

• Integration, typically 30–50% of license cost in the first year, higher in complex environments. Connecting the platform to existing systems is a project, and it is usually the buyer's project.
• The unserved remainder. A platform covering 80% of the requirement leaves 20% living in manual process, spreadsheets, or custom bolt-on code that the organization owns and maintains without vendor support.
• Data extraction. Whether a complete, usable export exists, in what format, and how much reconstruction it requires. Evaluate this before signing, because the evaluation is not possible from a position where leaving is already expensive.
• Price escalation. Renewal increases and per-seat growth over a five-year horizon, compared against a build's declining marginal cost.
• Version upgrades, particularly where customization has been applied. Each customization is retested and frequently reworked.
• Administration. Configuration, user management, and vendor relationship management consume internal time indefinitely.

Costs omitted from the build case

The estimate covers construction. Production systems incur cost from the day they ship.

• Ongoing maintenance, typically 15–20% of build cost annually: security patches, dependency updates, defect fixes, and platform upgrades. Indefinite, and rarely in the business case.
• Operational support. Monitoring, incident response, and the on-call obligation that comes with a system the business depends on.
• Knowledge risk. A custom system is maintainable by the people who understand it. That is a hiring and documentation obligation for the system's life.
• Opportunity cost. Engineering capacity spent here is not spent on the product.

The default and the exception

Default to buying, and require a specific written justification to build.

Custom software is harder than it appears, takes longer than estimated, and requires operational capabilities organizations consistently underestimate. The appeal of a purpose-built system does not survive a two-year maintenance backlog and the departure of its author.

The exception holds when three conditions are met simultaneously:

• The capability is genuinely core to how the business competes
• Requirements are specific enough that evaluated vendor platforms consistently fail them, demonstrated by evaluation rather than assumed
• The organization has capacity to build and to maintain the result, budgeted for both

Where those hold, the build produces an appreciating asset. SaaS costs rise annually and indefinitely; a working internal system is paid for principally once and maintained at a fraction.

Running the comparison

Compare five-year total cost, not first-year cost, with the omitted categories above included on both sides.

The comparison changes direction more often than expected. Buy decisions justified on first-year price frequently lose over five years once integration, the unserved remainder, and escalation are counted. Build decisions justified on a construction estimate frequently lose once maintenance and support are counted. Producing both figures takes about a week and is the least expensive part of the decision.