All field guides

AI decision framework

A workflow-level framework for build, buy, compose, or stop.

A practical AI build-versus-buy framework comparing build, buy, compose, and stop across cost, control, risk, time, and full-lifecycle operation.

Definition

The useful choice is not binary. Compare build, buy, compose, and stop against one capability contract and the same acceptance criteria.

01

Specify the capability before comparing options

A vendor product and an internal proposal cannot be compared until both are asked to satisfy the same workflow, rights, deployment, quality, and operating constraints.

One workflow

Name the trigger, inputs, accepted output, user or downstream system, failure consequence, volume, latency, and person accountable for the result.

Hard requirements

Separate non-negotiable rights, runtime, deployment, security, integration, and quality requirements from preferences. A cheap partial component is not a valid option for a complete service.

Acceptance contract

Define representative test cases, baseline, review burden, release gate, and stop condition before the team becomes invested in a particular path.

02

Map build, buy, compose, and stop

Give each path a fair version. A weak vendor shortlist and a heroic internal estimate merely formalize the preference the team already had.

Build

Estimate the smallest maintainable capability that meets the contract, including evaluation, tooling, CI, review, deployment, monitoring, and ownership—not just generation time.

Buy or compose

Check functional coverage, integration work, rights, data terms, portability, vendor viability, change control, and the cost of operating the acquired capability in your environment.

Stop

Include the option to preserve the current workflow or redesign it without AI when the expected outcome cannot earn the total cost or operating risk.

Inspect the FunctionFoundry estimation record
03

Model full ownership, not token price

The decision changes when integration, evaluation, review, failure, and change costs sit beside engineering and inference.

Creation and acquisition

Model engineering or agent effort, tools, compute, CI, purchase or subscription cost, procurement, and the work required to prove that the capability meets the acceptance contract.

Operation

Include context, inference, retries, orchestration, observability, human review, incident handling, failure remediation, and vendor or model changes.

Sensitivity

Show which assumptions can reverse the recommendation: volume, review rate, provider price, integration depth, model quality, internal reuse, or time-to-value.

04

Fund a bounded next move

A good comparison ends with an owned action and evidence gate—not a scorecard that leaves the same debate alive.

Recommendation

State build, buy, compose, stop, or evaluate-further; include the assumptions, confidence, disqualifiers, and evidence gaps capable of changing it.

Pilot charter

If uncertainty remains, fund the smallest pilot that resolves it. Name the cases, owner, timebox, cost ceiling, success threshold, and stop rule.

Decision boundary

Keep planning separate from execution. A comparison should not spend funds, create a purchase, or silently authorize production access.

Sources

Primary references and further reading.

Apply the framework

The decision is live. Build the evidence.

Bring the owner, deadline, current evidence, and the question capable of changing the next move.

Explore FunctionFoundry