Key takeaways
- Build versus buy is really manual versus configure versus create versus managed ownership.
- Buy when the process is common and adapting to the product costs less than maintaining uniqueness.
- Build when the process is differentiating, the controls are specific, and an accountable owner can carry the lifecycle.
- A managed agentic workflow can reduce specification and change effort, but does not remove approval, security, or evidence requirements.
- Use a reversible pilot and define the export, fallback, and retirement path before commitment.
Buy an internal tool when the process is common, the product's operating model is acceptable, and configuration plus change management cost less than owning custom software. Build when the workflow is differentiating, controls or integrations are specific, and a team can own delivery and operation. Use a managed agentic workflow when teaching and adapting the process is the larger cost, while retaining explicit gates and evidence. Keep or improve the manual process when volume, stability, or benefit cannot repay any option.
The real decision has four options
“Build versus buy” hides two useful alternatives: operate the process manually with better discipline, or use a managed workflow where specification, execution, and adaptation share one loop. Start from the internal-tool lifecycle, then decide which responsibilities you want to own and which a provider must carry.
| Option | Best when | You still own |
|---|---|---|
| Manual or assisted | Low volume, changing policy, high novelty, easy human coordination | Training, queue discipline, quality, evidence, and capacity |
| Buy and configure | Common job, acceptable product model, standard controls and integrations | Configuration, access, adoption, data, exceptions, vendor change, and exit |
| Build in-house | Differentiating workflow, specific controls, durable engineering capacity | Product, engineering, security, reliability, support, change, and retirement |
| Managed agentic workflow | Process knowledge is difficult to specify and bounded judgment or frequent adaptation matters | Policy, authority, examples, approvals, review of failures and changed behavior |
Compare lifecycle cost, not the first invoice
| Cost category | Questions |
|---|---|
| Discovery | Who observes the work, resolves disagreement, and defines exceptions? |
| Delivery | Who configures, integrates, migrates data, tests, secures, and trains? |
| Run | What are recurring licenses, usage, review, exceptions, monitoring, and support? |
| Change | Who detects dependency or policy drift, patches, retests, approves, and communicates? |
| Failure | How is impact contained, external state reconciled, fallback activated, and evidence preserved? |
| Exit | Can the team export data, revoke access, retain required evidence, and continue the work? |
NIST's SSDF treats preparation, protection, production, and vulnerability response as ongoing secure-development outcomes. Buying changes who implements those practices; it does not make your requirements, configuration, data, or access decisions disappear.
Use decision rules you can defend
- Buy when at least 80% of the value comes from a common pattern and adapting the remaining work is cheaper than maintaining uniqueness.
- Build when the unique process creates durable advantage or required controls cannot be expressed safely in available products.
- Use managed delivery when process discovery and continuing adaptation dominate implementation effort, and the provider can show authority, tests, evidence, and repair boundaries.
- Stay manual when volume is low, policy is changing, outcomes resist verification, or no accountable owner exists.
Make the proof answer ownership questions
- 01Set a cost and risk ceilingHuman approvalUse the ROI threshold and the highest-consequence action to define what an option must beat.
- 02Test real exceptionsCodeUse representative cases, missing inputs, duplicates, stale data, a denied permission, and a downstream timeout.
- 03Change a dependencyTriggerSimulate a renamed field or new required value and observe detection, failure, fallback, repair, and retest.
- 04Verify the exitHuman approvalExport necessary data and evidence, revoke credentials, and run the manual fallback.
- 05Record the decisionHuman approvalState the chosen option, assumptions, owner, review date, rejected alternatives, and reversal trigger.
Limitations and when not to use this
- The percentages and examples are decision aids, not universal procurement thresholds.
- This guide does not evaluate current vendors, contracts, prices, features, or security controls. Verify those with dated official evidence and a proof.
- Managed delivery does not transfer your organization's accountability for policy, data, people, approvals, or regulated outcomes.
Sources
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 14 August 2026
- Secure Software Development Framework 1.1 — NIST Accessed 14 August 2026
Set the cost ceiling
Calculate what the process can afford per month, then compare options inside that ceiling with risk and ownership alongside price.
Set the cost ceilingUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.