Build vs buy

Yes: Control over behavior and iteration may justify building.

Check: Identify the specific behavior a vendor cannot provide.

No: Buying could save time if integration and ongoing fees are reasonable.

Check: Run a fit test using your hardest workflow.

Not agreed: The decision depends on product strategy.

Check: Ask product and sales which outcomes buyers actually value.

Yes: Build remains a viable option.

Check: Estimate maintenance, security, and support ownership.

No: Building would create an operating gap.

Check: Compare vendor support, integration, and exit costs.

Unclear: Delivery capacity is unproven.

Check: Pilot the hardest slice before a long-term commitment.

Yes, supported by evidence: Both options can be compared on the same difficult behavior.

Check: Retain unsupported cases and confirm which are genuinely mandatory.

Partly, with known gaps: One option or a common case is tested, leaving an uneven comparison.

Check: Run the same exception, failure and integration cases for both options.

No, the check is not met: Feature lists alone cannot establish which option delivers the required outcome.

Check: Run the same exception, failure and integration cases for both options.

Unknown, not verified: Missing evidence prevents a conclusion. Use real acceptance criteria and allowed synthetic data. A vendor demo and a custom prototype are not equivalent evidence.

Check: Run the same exception, failure and integration cases for both options.

Yes, supported by evidence: The comparison includes the work around the core implementation.

Check: Record owners and upgrade acceptance checks for each interface.

Partly, with known gaps: Initial integration is considered, but maintenance or upgrades remain unowned.

Check: Map required interfaces and estimate their first delivery and recurring maintenance separately.

No, the check is not met: The apparent faster option may transfer work into an unmanaged integration layer.

Check: Map required interfaces and estimate their first delivery and recurring maintenance separately.

Unknown, not verified: Missing evidence prevents a conclusion. Account for identity, data mapping, upgrades and external dependencies. Buying does not remove integration work.

Check: Map required interfaces and estimate their first delivery and recurring maintenance separately.

Yes, supported by evidence: The required controls have comparable evidence for both choices.

Check: Have the security owner retain the evidence and scope of any accepted exception.

Partly, with known gaps: Some controls fit, but exceptions may require a design or contract change. Resolve the prerequisite's remaining gaps before making the stated commitment.

Check: Review one sensitive data flow and a denied-access case with the security owner.

No, the check is not met: An option fails a stated control prerequisite and needs remediation or a different scope.

Check: Review one sensitive data flow and a denied-access case with the security owner.

Unknown, not verified: This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Check actual data flows, tenant isolation, privileged access and deletion requirements, not a generic compliance badge.

Check: Review one sensitive data flow and a denied-access case with the security owner.

Yes, supported by evidence: The cost comparison is bounded to equivalent workload and time assumptions.

Check: Run an explicit higher-usage or higher-support scenario with the same inputs.

Partly, with known gaps: Base prices are known, but omitted lifecycle costs may change the result.

Check: List entered costs, period, usage basis and exclusions before calculating a difference.

No, the check is not met: A build budget and a subscription price are not yet a fair comparison.

Check: List entered costs, period, usage basis and exclusions before calculating a difference.

Unknown, not verified: Missing evidence prevents a conclusion. Include licenses, internal operations, support, integration, growth assumptions, overlap and exit, without mixing currencies.

Check: List entered costs, period, usage basis and exclusions before calculating a difference.

Yes, supported by evidence: Continuity does not depend entirely on one supplier or individual.

Check: Keep a representative restore or handover record and an accountable owner.

Partly, with known gaps: A fallback exists, but restoration or handover evidence is incomplete.

Check: Rehearse how the service continues if its primary maintainer or supplier is unavailable.

No, the check is not met: The choice creates a continuity dependency without a recovery path.

Check: Rehearse how the service continues if its primary maintainer or supplier is unavailable.

Unknown, not verified: Missing evidence prevents a conclusion. For custom work, include key-person dependency; for purchased software, include vendor support and usable export paths.

Check: Rehearse how the service continues if its primary maintainer or supplier is unavailable.

Yes, supported by evidence: The next experiment can inform the choice before the commitment window closes.

Check: Review results against the predefined decision and stop rules.

Partly, with known gaps: A pilot exists, but its acceptance or stopping condition is unclear.

Check: Select one decisive unknown and agree the owner, deadline and evidence that would change the choice.

No, the check is not met: More experimentation may consume the decision window without reducing uncertainty.

Check: Select one decisive unknown and agree the owner, deadline and evidence that would change the choice.

Unknown, not verified: Missing evidence prevents a conclusion. Name the decision deadline, experiment owner, cost limit and stopping rule. A pilot should not quietly become the commitment.

Check: Select one decisive unknown and agree the owner, deadline and evidence that would change the choice.