Build, buy, or neither

6 min read

Why cost alone no longer decides build vs. buy, and the five questions that do

AI coding tools made building software cheaper, and that tempts companies to treat build vs. buy as a cost comparison that building now wins. A cost comparison leaves out what decides most of these calls: what one bad output costs, how long a qualified person needs to review AI-generated code, and whether the vendor’s price will last. Make the call one capability at a time, and most systems come out as a mix: some parts bought, some extended, some built, some left with a person.

A capability is one job the software does, such as scheduling, routing, or invoicing. A dispatch platform, an ERP, or a CRM is a bundle of them, and each can land somewhere different. Five questions, answered with numbers, sort each capability into one of six outcomes. The case at the end splits one dispatch system three ways, with an extension that pays back in about ten months where a replacement would have rebuilt what already worked.

AI made building cheaper and moved risk on both sides

Agentic coding tools cut the cost of building. In McKinsey’s 2026 State of AI survey, 32 percent of respondents said their organizations had decided against buying at least one software product or feature because they could build it in-house with agentic coding tools [1]. Among the companies McKinsey classes as AI high performers, nearly half said so.

Risk moved as well. On the buy side, much of today’s AI tooling is priced below what it costs the vendor to deliver. Vendors are moving heavy users to usage-based pricing, and a vendor still losing money may fail instead of repricing, which forces a migration on the vendor’s timeline.

On the build side, risk sits in ownership. Tools built quickly by whoever had access to a coding assistant end up connected to production data with no review and no owner. In Protiviti’s February 2026 AI Pulse Survey, 65 percent of organizations reported challenges with shadow AI, meaning AI systems deployed or used without proper oversight [2]. In my remediation work, the code is the cheap part. The expensive part is finding out what a tool does, what data it touches, and who depends on it.

Five questions sort each capability

Some of these are engineering questions. Put them to your engineering lead, and ask for numbers.

1. Volume. Is there enough use to pay for ownership? Upkeep, security, testing, and a named owner cost roughly the same whether 20 people use a tool or 2,000. Low volume points to buying, or to a person.

2. Cost of one bad output. A wrong label on an internal report costs almost nothing. A wrong figure on a customer invoice or a regulatory filing is material. The higher the cost of an error, the more testing and review a build needs, and the more a vendor’s certification is worth.

3. Same input, same output. Does the capability need to give the same answer every time, for audit, reconciliation, or safety? If so, AI can help write the code, but no AI model should make the decision, because no model answers the same way every time. Safety-critical systems go further: buy certified, or build with traditional engineering.

4. Review time. Does reviewing AI-generated code take much less time than writing it by hand? If review takes nearly as long, AI assistance adds cost instead of saving it, and the capability belongs with traditional engineering or a vendor.

5. Substitutes. Can configuration, an extension, a rules engine, a hire, or a process change get the same result for the same or less, counting every cost and the time to production? If one can, building has to prove it’s better.

Payback. When the decision replaces something you already run, it has to pay back. Compare the annual savings with the one-time cost to switch: the build, a period of running old and new side by side, integration, and retraining. A tool that misfits only at the margins is often cheaper to keep and govern than to replace.

Stress both sides before deciding: vendor repricing or failure on the buy side, owner turnover and security review on the build side.

The questions come from The Price Is Not the Price, where they decide whether an AI workload belongs on a model. Here they decide which outcome a capability gets.

Each capability lands in one of six outcomes

The answers point each capability to one outcome. Where your company competes on a capability, fit to your workflow is worth more, which pushes that capability toward extending or building.

Outcome	Choose it when
Buy as is	The process is a commodity, the product fits, and the vendor is profitable
Buy and extend	The product fits except at the edges, and the vendor offers stable APIs that survive upgrades
Build with AI assistance	The misfit is core, volume is high, review is fast, and someone owns the result
Build with traditional engineering	Errors are costly, or the same input must always give the same output
Hire or redesign the process	Volume is low and the call needs human judgment
Keep and govern	The current tool misfits only at the margins, and switching pays back slowly

A composite case: one system, three outcomes

This example is a composite, built to show how the test sorts a real system. The figures are illustrative.

A regional distribution company runs field-service dispatch on a SaaS platform. The platform assumes technicians work fixed territories. The company routes jobs by certification and truck inventory, so its eight dispatchers keep a spreadsheet beside the platform and reassign jobs by hand. The first instinct is to replace the platform with something built in-house, now that AI makes building cheap. Run capability by capability, the test says otherwise.

Scheduling, the technicians’ mobile app, and invoicing are commodity capabilities. The platform handles them well, and the vendor is established and profitable. They stay bought as is.

Routing is where the platform fails. Every job passes through it, so volume is high, and a bad assignment costs a missed service window or a second truck roll. Dispatchers and auditors need to see why a job went where it did, so routing has to be a rules layer that gives the same answer for the same job. Rules code is quicker to review than to write, so AI assistance pays. The platform exposes a dispatch API, so the outcome is buy and extend: a routing service built with AI assistance and plugged into the platform, with every generated change reviewed and a named owner after launch.

Emergency jobs, a small share of the total, override the rules. They are low volume and high judgment, so a senior dispatcher keeps them. That is the third outcome: a person owns the decision.

The extension takes two engineers three months. At a loaded cost of $15,000 per engineer-month, that’s $90,000. Add $15,000 for a month of running the spreadsheet process alongside the new service, and the one-time cost is $105,000. Upkeep is a quarter of an engineer, $45,000 a year, plus $10,000 for hosting. The return is the dispatchers’ manual reassignment time: two hours a day each, at a $45 loaded hourly rate over 250 working days, or $180,000 a year. Net of upkeep, the extension saves $125,000 a year and pays back in about ten months.

The conclusion rests on the measured hours. If upkeep needs half an engineer instead of a quarter, payback stretches to about sixteen months and still holds. If the reassignment time turns out to be half the estimate, payback runs three years and the extension becomes a marginal call. Measure the hours before building. Replacing the whole platform would have meant rebuilding three commodity capabilities to fix one.

Outcomes change when prices and tools change

An outcome is a finding at a point in time. A vendor repricing, a new API, a drop in build cost, or a change in error tolerance can move a capability from one outcome to another. Re-run the five questions when any of those changes, and at every renewal.

Questions about a build decision: dave@dave-nix.com

Notes

[1] McKinsey & Company, “The state of AI in 2026: On the road to ROI,” August 25, 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

[2] Protiviti, “No Visibility, No Confidence,” fourth AI Pulse Survey, conducted February 2026 with about 345 executives, board members, and IT leaders; released May 7, 2026. https://www.protiviti.com/us-en/press-release-ai-pulse-half-enterprises-lack-ai-visibility