Build, buy, rescue, or stop?

A struggling AI initiative attracts confident prescriptions. Engineering wants a rebuild. Procurement has found a product. The sponsor wants to save the prototype, and finance asks whether the project should stop.

All four responses can be sensible. The trouble starts when the team treats them as identities. A company does not need to be a “builder” or a “buyer.” It needs to decide what work deserves funding next, based on what it knows now.

I use build, buy, rescue, and stop as investment decisions, not final architectures. A bought product still needs integration. A custom workflow will probably use commercial services. A rescue may replace half the system, while stopping an agent may leave a useful fixed workflow behind.

Start with the work as it exists

Before comparing products or architectures, write a short account of the current workflow. Name its trigger, owner, systems, and completion point. Record volume, elapsed time, staff time, corrections, and the cost of the mistakes that matter.

The numbers need only be good enough to expose a weak case. A rare task with tiny time savings will not support much software. If one error can delay payment or expose private data, average handling time tells only part of the story.

Assemble representative examples from the queue, including incomplete inputs, policy exceptions, and past failures. Protect sensitive information as required. Use these cases to test each option. Otherwise, every demonstration will favor the examples that make its option look best.

NIST’s AI Risk Management Framework Core asks teams to compare expected benefits and costs with benchmarks, including error costs and human oversight. Compare each option with today’s process, not with a polished demo.

Set two gates before you score options

The first gate concerns the outcome. Can the team define an acceptable result and recognize a bad one? A drafted customer response may need to be factually correct, follow policy, and escalate the right cases. If reviewers cannot agree on the target, implementation will not settle it.

The second gate concerns ownership. Is someone responsible for exceptions, changes, and slipping performance? Without that owner, the project is an experiment, regardless of its production credentials.

Pass both gates before using a weighted spreadsheet. Scoring an option to two decimal places can make an undefined outcome look rigorous.

What each choice commits you to

Path	Strong signal	Burden people miss	Evidence for the next decision
Buy	The capability is common and mature products fit the workflow	Integration, supplier risk, configuration, and exit planning	A trial on your cases, with contract and security review
Build	The workflow or policy is distinctive and control matters	Evaluation, maintenance, model changes, and on-call ownership	A thin working slice that beats the baseline
Rescue	The current system contains useful assets and its main failure is identifiable	Sunk-cost bias and an open-ended refactor	One bounded change with a deadline and a rerun of the case set
Stop	The outcome, owner, economics, or risk boundary does not hold	Pressure to keep a visible project alive	A written stop reason and a condition for reconsidering it

This is not a four-way feature comparison. Each path fails for different reasons.

Buy when the capability is ordinary

Buy when the problem is common, credible products exist, and normal configuration fits the work.

The product still has to work inside a service. The UK government guidance on assessing AI solutions notes that bought AI still needs integration, and that the decision depends on the uniqueness of the need, product maturity, and fit with existing infrastructure.

Run the vendor on your case set. Ask for inspectable results rather than one accuracy claim. Test low-confidence handoffs and ask what happens after model changes. Review data retention, access controls, incident notification, exports, API limits, and termination assistance.

The UK Government AI Playbook recommends covering data, integration, support, hidden costs, intellectual property, liability, and vendor lock-in. Put those questions into the trial and contract while the team has leverage.

A license shifts some engineering responsibility to a supplier. It does not transfer accountability for the outcome your users receive.

Build when the workflow is part of the advantage

Build when valuable behavior comes from your policy, data, or system connections, and a product would force the work into the wrong shape. Control over evaluation, releases, or data boundaries may also justify it.

“Build” rarely means training a foundation model. More often, the team owns orchestration, retrieval, permissions, evaluation, and the interface while using external models. Document that boundary so supplier dependencies remain visible.

Start with one slice that a real user can complete, including authentication, logging, a failure path, and correction. A prototype that only proves a model can answer has not tested the expensive part of building.

The in-house team must be able to run what it creates. The same UK guidance covers both development skills and operational maintenance. A contractor cannot become the permanent owner by default.

Rescue only a testable asset

Rescue when the project has a useful integration, case set, interface, or policy layer, or when one bounded problem explains most failures. “We have already spent six months” is not an asset.

Freeze feature work and establish the current result. Inspect failures before changing architecture. Are source facts missing, is policy unsettled, or does the system have weak tools and permissions? Each diagnosis points to different work.

Test one causal claim. For example: “Most incorrect resolutions retrieve superseded policy.” Fix retrieval and rerun the cases. Reject the claim if the expected improvement does not appear. Rescue cannot become unrelated rewrites that avoid the baseline.

Give the rescue a deadline and exit rule. If nobody can isolate a dominant failure, rebuilding a narrow slice or stopping may cost less than preserving the prototype.

Stop when a precondition is missing

Stopping is a normal product decision. It is warranted when the workflow has no owner, the outcome cannot be evaluated, the volume cannot support the operating cost, required data cannot be used lawfully, or the available controls do not match the consequence of failure.

A team can stop autonomous action while keeping a routing rule, search interface, or drafting assistant. Manual work may remain the safer choice until policy or source data improves.

Record what fact would reopen the project. “Reconsider when the source system exposes a supported API” is useful. “Revisit AI next year” is not.

Count the cost outside the model call

Model and license prices are visible, so they receive too much attention. A useful first-year cost view includes acquisition, integration, evaluation, user training, support, monitoring, incident response, and the work required to change or leave the solution. Estimate staff time as well as cash.

Use ranges for uncertain usage or supplier costs. Identify which unknown could change the decision, then design the trial to answer it first.

NIST also includes third-party AI controls and contingency plans for supplier failures. A small tool does not need a vast governance program, but “the vendor handles it” is not a continuity plan.

A hypothetical decision

Consider a hypothetical field-service company that receives quote requests by email. Coordinators read attachments, identify the site and equipment, request missing details, check service coverage, and prepare a quote for approval. An early prototype extracts the request and drafts a response, but it also tries to select prices and send the email.

The case review finds that extraction works, while pricing fails because contract exceptions live in several spreadsheets. The team can evaluate extraction and missing-information detection, but not autonomous pricing across every contract variation.

Buying a full “autonomous quoting” product would not remove that policy problem. Building the whole system again would preserve too much scope. Stopping would discard a useful extraction step. The next move is a rescue: keep the intake integration, remove autonomous send and pricing, connect the current contract table, and test whether the system can prepare a complete review packet for a coordinator.

That may later lead to a hybrid design. The company could buy document processing, build its policy checks, and leave price approval with a person. The point of the four-way decision was to choose the next investment, not to force the final service into one category.

Leave a decision someone else can audit

The decision record can fit on one page: workflow, baseline, chosen path, evidence, main risk, owner, review date, and reversal condition. Link the case set and cost assumptions.

Then fund only the next proof. A buyer earns a wider rollout by passing the trial. A builder earns more scope by beating the current process. A rescue earns another iteration by confirming its causal claim. A stopped project stays stopped until its recorded condition changes.

That is enough discipline to prevent a technology preference, a good demo, or yesterday’s spending from making tomorrow’s decision.

Further reading

• Assessing if artificial intelligence is the right solution, UK Government
• Artificial Intelligence Playbook for the UK Government, UK Government
• AI Risk Management Framework Core, NIST
• Secure by Demand Guide, CISA