Build vs. Buy

What this is and who it’s for

This is a decision framework for whether to build custom software, buy and configure a commercial product, or adopt and extend open source for a given capability. It’s for an agency CIO or senior technical lead who has a funded requirement and has to defend the path they pick. The framework reduces to one question — is this capability a differentiator, or is it a commodity? — and a method for pricing each option by total cost of ownership rather than sticker price. Use it before procurement starts, because the decision you make here dictates which contract vehicle you can use.

Prerequisites

A clear, written requirement. If you can’t state what the capability must do in a paragraph, you can’t evaluate options against it, and a vendor demo will define the requirement for you.
The total-cost-of-ownership method. Read the Total Cost of Ownership runbook and have a TCO model ready before you compare options — every option in this framework is scored on TCO, not license cost.
A realistic read of your internal engineering capacity. The Engineering Team Operating Model runbook describes the staffing a “build” path commits you to indefinitely.

The practice

Start with one question: differentiator or commodity?

Sort the capability into one of two buckets before you evaluate any option. A differentiator is mission-specific — it encodes how your agency does something no vendor models, and doing it well advances the mission. A commodity is a solved problem every organization needs and no one wins by reimplementing: authentication, email delivery, payments, document storage, identity.

The rule follows directly: build the differentiators, buy the commodities. Spending scarce engineering capacity rebuilding a commodity is the most common and most expensive mistake an agency makes, because you pay to build it and then pay forever to maintain something a vendor maintains for everyone. Spend your build budget where the work is mission-specific and a vendor can’t follow you.

The four options

Evaluate each viable option on three things: when it fits, the real cost, and the lock-in/control tradeoff.

Build custom

When it fits: the capability is a genuine differentiator, the requirement is stable enough to justify the investment, and you have — or can sustain — the engineering team to own it for its full life.

The real cost: you own it forever. The build is the cheap part; the expensive part is the years of maintenance, security patching, dependency upgrades, and on-call that follow. Budget for a standing team, not a project. See the Engineering Team Operating Model for what that team costs.

Lock-in/control tradeoff: maximum control, zero vendor lock-in — but you’re locked into your own staffing. If the team disperses, an unmaintained custom system becomes a liability faster than a vendor product does.

Buy COTS or SaaS

When it fits: the capability is a commodity, a product on the market fits your requirement closely without heavy customization, and the procurement path is open to you.

The real cost: the license is the visible cost; the hidden costs are integration, configuration, customization debt, and per-seat scaling as you grow. A product that fits 80% of the requirement out of the box is a good buy; one that fits 50% becomes a customization project priced like a build with none of the control.

Lock-in/control tradeoff: least effort to stand up, least control. Confirm an exit before you sign — data export, contract-end terms, and migration cost. “Buy with no exit” is how a commodity decision turns into a decade of captive renewals.

Configure a platform (low-code / government platform)

When it fits: the requirement is largely a workflow, form, or case-management problem, and a platform your agency already licenses (or a sanctioned government platform) can model it through configuration rather than code.

The real cost: configuration is cheaper than code until it isn’t — complex requirements push you into platform-specific scripting that only a small market of specialists can maintain. Price the platform license plus the configuration labor plus the specialist dependency.

Lock-in/control tradeoff: moderate control, high platform lock-in. Your logic lives in the platform’s proprietary model and rarely ports out. Good for stable workflows you don’t expect to move; risky for anything you may need to re-platform.

Adopt and extend open source

When it fits: a mature open-source project covers most of the requirement, the license permits your use, and you have the capacity to extend and maintain a fork or contribute upstream.

The real cost: the software is free; the ownership is not. You inherit the maintenance burden of your extensions and the upgrade burden of tracking upstream. Budget either internal capacity or a paid support/services contract.

Lock-in/control tradeoff: high control, low vendor lock-in, but real key-person and capacity risk. You avoid the vendor but not the obligation to sustain what you run.

The government-specific angle

Policy often pushes agencies toward “buy” — and for true commodities that’s the right default. But the preference becomes a trap when a poorly-fit COTS product is procured to satisfy policy and then customized into a bespoke system: you pay vendor margins and integration labor to end up with something you maintain like custom software, minus the control. A close fit is the whole point of buying; a poor fit erases the advantage.

“Build” carries the opposite government-specific risk. It requires sustained internal engineering capacity that most agencies don’t have and can’t quickly hire, so a build that ships without a staffing plan decays the moment the project funding ends. Don’t choose “build” unless you can answer who maintains it in year three. Maryland-specific procurement preferences and policy defaults are [VERIFY] — confirm with your procurement office before treating any default as binding.

Decide on total cost of ownership, not sticker price

Score every option on TCO over a realistic horizon (typically five years), not on license or build cost in year one. The cheapest sticker price routinely loses to the option with lower integration, maintenance, and exit costs. Build the TCO model first using the Total Cost of Ownership runbook, then feed each option’s TCO into the scorecard below.

Reference implementation

Two artifacts, both forkable. The first scores the options; the second records why you chose one.

Decision scorecard

Score each option against weighted criteria. Weights sum to 1.0; adjust them to the decision. Score each cell 1–5 (5 is best), multiply by the weight, and sum the column. Highest weighted total wins — but treat it as input to judgment, not a verdict.

## Build vs. Buy Decision Scorecard

| Field    | Entry |
| -------- | ----- |
| Capability |     |
| Date       |     |

Differentiator or commodity?  [ ] Differentiator   [ ] Commodity

| Criterion           | Weight | Build | Buy COTS/SaaS | Platform | Open Source |
| ------------------- | ------ | ----- | ------------- | -------- | ----------- |
| Differentiation fit | 0.20   |       |               |          |             |
| Requirement fit     | 0.20   |       |               |          |             |
| Total cost (TCO)    | 0.20   |       |               |          |             |
| Time to value       | 0.15   |       |               |          |             |
| Lock-in / exit      | 0.15   |       |               |          |             |
| Internal capacity   | 0.10   |       |               |          |             |
| Weighted total      | 1.00   |       |               |          |             |

Scoring: 1 = poor fit / high cost / high lock-in
         5 = strong fit / low cost / low lock-in

## Recommendation

Decision-memo template

Record the rationale so the decision survives staff turnover and defends itself in review. Tie the memo to an architecture decision record — see Technical Decision-Making for the ADR format and where to file it.

## Build vs. Buy Decision Memo

| Field         | Entry |
| ------------- | ----- |
| Capability    |       |
| Decision date |       |
| Decision owner |      |
| Linked ADR    |       |

### 1. Requirement (one paragraph)

### 2. Differentiator or commodity, and why

### 3. Options considered and scorecard totals

| Option      | Total |
| ----------- | ----- |
| Build       |       |
| Buy         |       |
| Platform    |       |
| Open source |       |

### 4. Decision and the deciding factors

### 5. TCO summary (5-year)

| Field             | Entry |
| ----------------- | ----- |
| Chosen option TCO |       |
| Next-best TCO     |       |

### 6. Lock-in / exit plan

### 7. Sustainment plan (who owns and maintains this, and funding)

Common pitfalls

Building a commodity. You’re standing up a team to build authentication, email, or payments. If a capability is a solved problem every organization needs, buy it and spend the engineering on your differentiators.
Customizing a poor-fit COTS into a bespoke system. The product needed heavy configuration and custom modules to meet the requirement, and now you maintain it like custom software while still paying vendor margins. If fit is below ~70%, re-score build and open source.
Deciding on license sticker price. The chosen option was the cheapest to license and is now the most expensive to run after integration and maintenance. Decide on TCO; the Total Cost of Ownership runbook is the method.
Buying with no exit. You can’t get your data out cheaply and renewal is the only realistic option. Negotiate export and contract-end terms before signing, and score lock-in explicitly.
Building with no plan to sustain it. The system shipped, the project team dispersed, and no one owns it in year two. If you can’t name the standing team and its funding, don’t choose build.
Vendor demo dazzle over requirement fit. The decision tracked the slickest demo rather than the written requirement. Score every option against your requirement, not against the vendor’s highlight reel.

Procurement notes

The decision you make here selects the procurement path, so finish this framework before procurement starts.

Build custom

Procure engineering services on a custom-development statement of work. The requirement and acceptance criteria from your decision memo become the SOW’s scope — see How to Write a Good SOW.

Buy COTS or SaaS

Procure as a product or subscription purchase. Carry the fit assessment, integration scope, and exit terms from the decision memo into the purchase requirements.

Adopt and extend open source

The software needs no purchase, but the sustainment usually does — procure a support or services contract for maintenance and upgrades, scoped like a services SOW.

Maryland-specific contract vehicles, thresholds, and any policy preference for “buy” over “build” are [VERIFY] — confirm with your agency procurement office before committing to a path.

Maintenance

Owner: [FILL IN: runbook owner] · Last reviewed: 2026-05-31 · Next review: 2026-08-31