Build vs Buy: Compare Lifecycle Cost, Control and Exit Evidence

Compare building, buying and composing a capability with explicit five-year assumptions, sensitivity tests, operational ownership and a practical vendor-exit rehearsal.

Compare the same outcome before comparing the options

A build estimate and a subscription quote often describe different things. One may include a custom workflow but omit support. The other may include hosting but exclude integration, migration or the plan needed for required controls.

Start with the capability the business needs: its users, required behavior, data, reliability, operating coverage and acceptable constraints. Then compare building, buying, composing a purchased core with a thin custom layer, and deferring the capability.

Differentiation is one input, not a rule that decides the answer. A distinctive customer experience may sit on a purchased service. A common capability may still require internal work because available products do not fit its constraints.

Separate disqualifying constraints from preferences

Write the requirements before scoring suppliers or internal proposals. For every constraint, name the person who can interpret or change it.

| Decision area | Evidence needed for a built option | Evidence needed for a purchased option | | --- | --- | --- | | Required behavior | Feasibility and acceptance tests | Demonstrated fit using representative workflows | | Data and access | Architecture, permission model and retention design | Supported controls, boundaries and tested export behavior | | Reliability | Staffing, recovery design and exercises | Service commitments plus customer-owned recovery and fallback | | Change control | Capacity to maintain and evolve the product | Versioning, deprecation, limits and extension constraints | | Exit | Portable data and maintainable interfaces | Contractual terms, export completeness and replacement effort | | Delivery timing | Available team and credible dependencies | Procurement, integration and adoption work, not signup time |

A weighted score should not hide a failed requirement. If a data boundary or recovery condition is mandatory, an attractive price does not compensate for its absence. Resolve the requirement or reject the option for that scope.

Security work exists on both sides. NIST's Secure Software Development Framework provides a vocabulary for development practices and supplier conversations. Referencing a framework is not evidence that a product or internal team implements it. Ask for the relevant artifacts and responsible owners.

Assign the work that remains after purchase

A vendor may maintain its product and infrastructure, but your organization still owns its configuration, identities, integrations, permitted data and customer outcome. The exact boundary depends on the service and agreement.

For a built product, identify who maintains dependencies, handles incidents, patches vulnerabilities, supports users and funds changes after the initial project. “The engineering team” is not enough if its future roadmap has no capacity for that work.

For a purchased product, identify who handles failed synchronizations, license changes, administrator access, data-quality problems and vendor incidents. Check whether several critical workflows would share the same provider or integration dependency.

A hybrid option deserves the same scrutiny. A thin adapter can preserve a useful boundary, but a growing collection of custom workarounds can become an internally maintained product wrapped around a subscription.

Use a transparent lifecycle-cost scenario

The following five-year example is entirely hypothetical. It compares a built internal workflow tool with a purchased tool supporting the same assumed scope. The values are not vendor quotes, Ampity prices, benchmarks or predicted customer outcomes.

Assume implementation and migration occur before five full years of operation. Annual costs are flat in the base case. Amounts are nominal US dollars in thousands, with an exit allowance at the end of year five. The example excludes tax, financing, discounting and residual asset value; use your organization's finance method when those affect the decision.

| Cost item | Build, $000 | Buy, $000 | | --- | --- | --- | | Initial implementation or integration | 180 | 60 | | Migration and adoption | 30 | 20 | | Internal maintenance, administration and support | 70 × 5 = 350 | 24 × 5 = 120 | | Vendor subscription | 0 | 72 × 5 = 360 | | Customer-paid infrastructure and related services | 18 × 5 = 90 | 6 × 5 = 30 | | End-of-period exit or replacement allowance | 40 | 60 | | Five-year modeled total | 690 | 650 |

The purchased service's hosting is assumed to be included in its subscription, while the buyer still pays for its integration infrastructure. The internal labor lines use allocated, fully loaded effort under the example assumptions. Replace each input with an owner, evidence source, date and uncertainty range.

Neither option is free of maintenance. The base case merely assigns different kinds of work to different parties.

Do not automatically add a percentage for “opportunity cost” on top of labor already counted. Identify the alternative work displaced, its business consequence and whether that consequence is already reflected elsewhere in the model. Keep uncertain benefits separate from committed cash or capacity costs.

Test the assumptions that can reverse the choice

In the base case, buy is $40,000 lower over five years. That difference is smaller than several plausible changes to the invented inputs. The scenarios below change one assumption at a time; they are not forecasts or probability estimates.

| Changed assumption | Revised result | What to investigate | | --- | --- | --- | | Subscription is 20% higher in every operating year | Buy adds $72,000, reaching $722,000 | Usage units, required plan, renewal terms and growth | | Build maintenance effort is 20% higher each year | Build adds $70,000, reaching $760,000 | Support coverage, dependencies and change demand | | Buy needs an additional $80,000 integration | Buy reaches $730,000 | Missing APIs, data transformations and workflow gaps |

Do not average these scenarios into a precise expected value without defensible probabilities. Use them to identify the next useful test or commercial question. A proof of concept that eliminates an uncertain integration assumption may be more valuable than another high-level comparison matrix.

Also compare delivery timing and failure consequences. A cheaper option that cannot meet a necessary date or data obligation may be unsuitable. A more expensive option may be justified, but the decision owner should state why.

Rehearse an exit instead of assuming reversibility

Buying is not inherently more reversible than building. A product can offer a data export while leaving permissions, identifiers, workflow rules or audit history difficult to reconstruct. A built system can be equally hard to replace if undocumented behavior and internal dependencies accumulate.

The UK government's technical lock-in guidance recommends weighing value against portability and considering the time and cost of switching. It is useful technical guidance, not a determination of contractual rights for your organization.

Use an authorized trial environment and representative, non-sensitive test data for an exit rehearsal:

Have the data owner define which records, relationships, attachments, histories and configuration must survive.
Ask the commercial owner to confirm permitted export, access after termination, assistance and applicable charges.
Export a representative sample through the supported mechanism, including a large or complex case.
Import it into a neutral model or candidate replacement and run the agreed completeness and permission checks.
Recreate a critical workflow without calling the original product.
Record elapsed work, manual repairs, missing fields and limits that could change the migration plan.

Keep deletion separate from migration. Do not remove the source environment or cancel necessary access until reconciliation, retention requirements and authorized acceptance are complete.

Make the rollout and return path explicit

A successful demonstration is not proof of operational fit. Pilot the selected option with a bounded population and named support owners. Test a failed integration, unavailable dependency, access removal and recovery from an interrupted migration.

Define where new records are authoritative during transition. Uncontrolled dual entry can create inconsistent states that neither system knows how to reconcile. If parallel operation is required, specify direction, conflict handling and verification.

Rollback needs more than restoring a user interface. New records, changed permissions and completed external actions may need reconciliation. Retain the previous supported path where safe until the replacement passes its acceptance gates. If the pilot fails, stop expanding it and decide whether to repair the option, narrow the scope or return to the alternative.

The central tradeoff is control versus obligation. Building can preserve a tailored capability while creating long-term product and operating responsibility. Buying can shorten initial delivery while introducing supplier, integration, pricing and exit dependencies. Composing several services can reduce custom code while increasing boundary and incident coordination. Compare those obligations, not only feature fit.

Write the decision memo

Build / buy / compose decision
  Capability and required outcome:
  Options compared, including defer:
  Mandatory constraints and owners:
  Fit evidence and unresolved gaps:
  Five-year assumptions, source dates and uncertainty:
  Sensitivity that would change the decision:
  Delivery timing and displaced work:
  Internal and supplier operating responsibilities:
  Exit rehearsal result and remaining dependency:
  Selected option and reasons:
  Accepted risks and authorized owners:
  Pilot acceptance, stop conditions and recovery:
  Revisit triggers:

A useful revisit trigger is a changed requirement, failed exit test, unsupported service limit or a cost assumption moving outside its accepted range. It is not simply dissatisfaction with a decision made under different facts.

"Every option is compared against the same required outcome.", "Mandatory constraints cannot be hidden by a weighted score.", "Internal operation and integration costs exist on both sides of the model.", "Hypothetical assumptions are separated from quotes and measured evidence.", "The decision survives the sensitivity scenarios the owner considers material.", "Data, workflow and access portability have been exercised.", "Pilot failure has a named response and a reconciled return path.", "Commercial, technical and risk decisions are owned by the relevant people." ]} />

Technology stack evaluation is the related technical assessment scope. Procurement terms, budget approval and risk acceptance remain with the appropriate business owners.

The immediate next step is to complete the decision memo far enough to identify the assumption most likely to change the answer. Test that assumption before committing to a long build or a long contract.