Build versus buy is usually argued as a philosophy when it should be settled as an inventory question. The teams that get it wrong are the ones treating it as a single decision about the whole AI program rather than a series of smaller decisions about individual capabilities, each with a different answer.
Almost no organization should build its own document storage, identity management, or transcription engine. Almost no organization should buy a product that encodes the specific logic distinguishing its operation from a competitor's. Between those poles sits the real question: for this particular capability, does the market already solve it well enough, and does our version need to be different?
The framework below works capability by capability. It starts with differentiation because that is the variable that determines everything downstream, then covers the tests that push a decision each way, the hybrid architecture most mature programs converge on, and the two costs — total ownership and lock-in — that make cheap decisions expensive later.
Sort Capabilities Before You Argue About Them
List every AI capability under consideration and place each into one of three buckets.
Commodity. Speech-to-text, OCR, translation, general document classification, embedding generation, standard chat interfaces. These are solved problems where dozens of vendors compete on price and accuracy. Building here means spending engineering time to reach parity with something you can buy on a monthly subscription. There is no strategic upside.
Contextual. Capabilities that are common in shape but depend on your data and rules to be useful — an assistant that answers questions from internal policy, a review queue for exceptions, a summarizer over your own records. The market sells frameworks and platforms here; the value comes from configuration and grounding, not from novel engineering.
Differentiating. The workflow that is genuinely yours: the underwriting logic, the pricing rules, the case-handling sequence refined over a decade, the decision your best operator makes that nobody has written down. If a competitor bought the same product and got the same result, the capability is not in this bucket.
Buy commodity. Configure contextual. Build differentiating. Most disagreements about build versus buy are actually disagreements about which bucket something belongs in, and running this sort explicitly resolves them faster than another round of debate.
Tests That Point Toward Buying
The process is standard and you have no reason to be different. Expense policy checks, resume parsing, invoice extraction. If your version of the process is unusual, ask whether that is a deliberate advantage or accumulated habit. Frequently it is habit, and adopting the standard is the cheaper improvement.
Your requirements will be met by the vendor's roadmap. A product with active development in your direction gives you improvements you did not pay to engineer. Check release notes over the past year rather than roadmap slides.
You lack the team to maintain it. AI software is not a fixed asset. It needs monitoring, evaluation, model updates, and integration repair. An organization without engineers who can own that should not accumulate custom systems, regardless of how compelling the initial build case looks.
Time to value dominates. If the capability needs to be live this quarter to matter, configuration beats construction. A product that covers seventy percent of the requirement now is often worth more than a bespoke system covering all of it later.
The compliance burden is heavy and generic. Certifications, penetration testing, and audit documentation are expensive to produce and identical for everyone. Buying inherits them.
Tests That Point Toward Building
The process encodes your actual advantage. If the sequence of decisions is what makes your operation work, handing it to a configurable product means either distorting the process to fit the product or fighting the product forever.
Your data shape has no product-market fit. Some organizations hold data that no vendor designed for — unusual document types, industry-specific structures, proprietary taxonomies. Products that assume a standard shape require so much workaround that the workaround becomes the system.
Integration is the requirement, not the model. When the hard part is connecting six internal systems that no vendor has connectors for, you are paying for a product's UI and buying none of the difficulty. The model is a component; the plumbing is the project.
Per-seat economics break at your scale. Seat-priced products are efficient for small teams and punishing for large ones. Where a capability touches thousands of users, the recurring cost can exceed a build within a small number of years.
You need control over the audit trail. Regulated environments sometimes require decision logging, retention, and reconstruction guarantees that a vendor cannot contractually provide. Where the auditor's requirement exceeds what the product exposes, the decision is made for you.
The Hybrid Split Almost Everyone Reaches
Mature AI programs rarely land on pure build or pure buy. They converge on a layered arrangement.
The infrastructure layer is bought: model access, vector storage, orchestration, identity, observability tooling. Building any of this is a distraction unless infrastructure is your business.
The application layer is built where it touches differentiating work and bought where it does not. A company might run a purchased AI assistant for general internal questions while a bespoke system handles the exception queue that constitutes its actual operational bottleneck.
The integration layer is almost always custom, because nobody else has your particular combination of systems. This is the layer teams consistently underestimate when they choose "buy" and expect it to be turnkey.
The critical design rule for a hybrid stack is that your data and your prompts and your evaluation sets remain yours, in your storage, in portable formats. That single constraint preserves the option to change any layer later, and it is far easier to insist on at procurement than to recover afterward.
Total Cost of Ownership on Both Sides
Comparisons usually fail because they measure a build's full cost against a product's subscription line and ignore everything else.
A build's true cost includes discovery and specification, engineering, evaluation infrastructure, integration work, deployment, then ongoing inference, monitoring, integration maintenance, and periodic modernization. Year-two costs are a meaningful fraction of year one and continue indefinitely.
A product's true cost includes the subscription, but also implementation and configuration, data migration, the custom integration work no vendor eliminates, internal administration, training, price escalation at renewal, and the cost of the residual gap — the work your team keeps doing manually because the product does not cover it. That last item is the one that never appears in a business case and frequently exceeds the subscription.
Compare over a realistic horizon. Products win decisively in year one and often in year two. The crossover, where it happens at all, tends to arrive later, and it arrives sooner at higher user counts and higher transaction volumes. Run the comparison at your projected scale, not your current one.
Lock-In Is a Real Cost, Not a Talking Point
Every option carries lock-in. The question is what kind and how expensive the exit would be.
Buying locks you into a vendor's data model, release cadence, pricing power at renewal, and continued existence. Consolidation in software markets means the product you selected may be sunset or deprioritized after an acquisition. The exit cost is a migration project plus whatever historical data you cannot extract cleanly.
Building locks you into your own architecture, your model provider unless you abstracted the interface, and the availability of people who understand the system. The exit cost is a rewrite, and the risk concentrates in key-person dependency and undocumented decisions.
Both are manageable with the same disciplines: keep data exportable in open formats, keep the model interface abstracted so providers can be swapped, document decisions rather than only code, and avoid architectures where one vendor owns the storage, the model, and the application logic simultaneously. These are the same portability questions that should drive any software selection process, applied to a faster-moving market.
Making the Call
Sort the capability into commodity, contextual, or differentiating. Run the tests on each side and see which list is longer. Compare total cost at projected scale rather than current scale. Then check the exit path on whichever option you favor.
If the answer still feels close, buy. A close call means the capability is not clearly differentiating, and the reversibility of a subscription is worth more than the theoretical fit of a build you have not scoped. Where the answer is genuinely build, the value comes from the process being specific, and the discovery work should confirm that before engineering starts — which is how Workisy approaches custom AI software development. If you are still mapping which layers to buy and which to build, the architecture patterns in our guide to the AI tech stack are a practical reference point.
