Build vs buy AI is really three options
For most small and midsize businesses, build vs buy AI is a choice among three options, not two: buy a finished tool, configure your own workflow on a platform or model API, or commission custom work from a developer or firm. Few businesses outside the technology industry should train their own models, so "build" usually means one of the last two.
The short answer: buy when the task is common and the vendor's terms fit your data. Configure when your own documents and workflow are what make the result good. Commission custom work only when the task matters competitively and someone will own the system after launch. Start with the lightest option that passes a test on your own examples, and step up only when it fails.
What each option means in practice
Buy a finished tool
A software product with AI built in, such as an AI receptionist, a meeting note-taker, or the AI features inside software you already use. You configure settings, not logic. The vendor chooses the model, the prompts, and when both change.
Configure on a platform or model API
You assemble a workflow from parts you do not own but do control: a model provider's API (the interface your software uses to send the model requests), an automation platform, or an AI assistant builder, connected to your own documents and systems. You write the instructions, choose the data it can see, and own the test cases. Someone on your side, or a contractor, maintains it.
Commission custom work
A developer or firm builds a system to your specification, often on the same model APIs, with custom integration, logic, and interface. You get the most control and take on the most responsibility, including after the original builder has moved on.
Build vs buy AI comparison: seven criteria
Read each row against your own task. One weak cell, such as data terms that do not fit, can rule out an option.
| Criterion | Buy a finished tool | Configure on a platform or API | Commission custom work |
|---|---|---|---|
| Differentiation | Low: competitors can buy the same tool | Medium: your data, instructions, and workflow are the difference | High, when the work is genuinely distinctive |
| Data sensitivity | Depends entirely on the vendor's terms and settings | You choose what data the workflow sees, within the provider's terms | You control the design; the builder and hosting terms still matter |
| Integration | Limited to the vendor's connectors | Moderate: whatever the platform and your systems allow | As deep as you pay for, and as fragile as it is complex |
| Maintenance owner | The vendor maintains the product; you maintain settings | You or a contractor maintain the workflow, prompts, and tests | You own it all after handover, unless you pay for ongoing support |
| Exit path | Depends on export features and contract terms | Moderate, if instructions and tests are documented | Good only if you own the code, prompts, tests, and documentation |
| Model-change risk | The vendor decides when the model changes, and may not tell you | You choose when to switch models, within the provider's retirement schedule | Same as configure, plus code that may need changes |
| Time to value | Fastest | Medium | Slowest |
How to choose: start light and step up
Write the test before you look at tools. Collect a few dozen real past examples of the task, each with the answer you would have accepted, and set a pass threshold before any trial starts. The same set judges every option on your work rather than a demo, and later it catches model changes.
Try a finished tool first, if one exists. Check that its data terms fit what the task touches (the AI vendor evaluation checklist lists the documents to request), then run it on your examples for a fixed trial. If it passes, stop here.
Configure when the gap is your data or workflow. If the bought tool fails because it cannot see your documents or follow your process, run a data readiness check on those documents, then build the workflow on a platform or model API and rerun the same examples.
Commission only when three things are true. The lighter options failed for reasons only custom work would fix, the task matters competitively, and someone is named to own the system after launch.
Write the exit path before you sign. Whichever option passes, record how you would leave it, using the exit questions below.
Cost categories to compare
Prices vary too much by vendor, volume, and scope for a general figure to help, so compare categories using quotes and your own volumes:
- Subscription or seat fees. Mostly the bought option.
- Usage fees. Per request, per amount of text processed, or per minute; present in all three, sometimes hidden inside a subscription.
- Integration. Connecting to your scheduling, CRM, accounting, or document systems.
- Testing and evaluation. Building and running the test set, before launch and after every change.
- Human review. Staff time spent checking output, in every option and often left out. The worksheet in how to measure AI ROI counts it as part of the new cost.
- Maintenance. Instruction updates, connector fixes, and monitoring.
- Model migration. Re-testing and adjusting when the underlying model is retired or changed.
- Exit. Exporting data, rebuilding elsewhere, and running both systems during the switch.
Buying moves most of these into the vendor's price. Configuring and commissioning move them onto your team or a contractor. None of them disappear.
Model-change risk applies to every option
AI models are retired and replaced on a schedule you do not set. Anthropic's model deprecations page (opens in a new tab), checked in October 2026, says the company provides at least 60 days' notice before retiring publicly released models, and that requests to retired models fail. Microsoft's Copilot documentation (opens in a new tab) says the models behind Copilot are regularly updated. In a bought tool, that change happens behind the product; in a configured or custom system, it lands on whoever maintains it.
NIST's Generative AI Profile (AI 600-1, July 2024) (opens in a new tab) calls this value chain and component integration risk: upstream components that are hard to trace or that reduce accountability for downstream users. It suggests vendor contracts cover how systems change over time, notification of serious incidents, and service levels for incident response (GV-6.2-007). The AI Risk Management Framework (opens in a new tab) adds monitoring of third-party resources and the pre-trained models a system depends on (MANAGE 3.1 and 3.2). NIST notes that the framework is being revised (opens in a new tab) as of October 2026, so recheck those outcome IDs before relying on them.
The defense is the same for all three options: rerun the test set from the first step whenever the model, the vendor, or your instructions change.
Write the exit path before you sign
Federal agencies have been told to plan for this. OMB memo M-25-22 (April 2025) (opens in a new tab), still listed on OMB's memoranda page (opens in a new tab) as of October 2026, directs agencies to pay attention to data portability and interoperability to avoid costly dependence on a single vendor, through protections such as knowledge transfer, data and model portability, clear licensing terms, and pricing transparency. It binds federal agencies, not private businesses, but the checklist translates directly:
- Can you export your data, logs, and configuration in a format another tool can use?
- Who owns the instructions, test cases, and any code written for you?
- How much notice do you get before price, model, or terms change?
- What happens to your data after you cancel, and for how long?
- Could a different vendor or contractor take over from the documentation alone?
A candidate that cannot answer these clearly carries a cost to price in. This is not legal advice; have counsel review ownership, licensing, data, and exit terms before you sign.
Build vs buy vs partner
Partnering means hiring an outside firm to configure or build for you. It is a way to commission the work, not a separate category, and it makes sense when you lack the people to configure and maintain a system yourself. Three conditions protect you: you own the code, instructions, and test cases; the handover includes documentation another contractor could follow; and someone, inside or outside, is named to maintain the system after launch.
Weigh any recommendation, this article included, by whether it shows its reasoning and whether its author profits from one of the options. If nobody inside the business can weigh the options, that is a leadership gap, not a technical one. The comparison of a fractional Chief AI Officer, an AI consultant, and a full-time hire covers ways to fill it.
Worked example: tenant maintenance replies
In this illustrative example, a thirty-person property management firm wants AI to draft replies to tenant maintenance requests for staff to approve.
- Buy. Its property management software offers an AI reply feature. It is fast to turn on, but it sees only data in that system and follows the vendor's general instructions.
- Configure. A workflow on a model API could read each request alongside the firm's maintenance policy and vendor list, and draft a reply for approval.
- Commission. A custom triage system could also route jobs and dispatch vendors. Routing is not what makes the firm different, so the extra control buys little.
Following the step-up sequence, the firm puts forty real past requests and good answers into a test set, then trials the bought feature against a pass threshold set in advance. If it fails on policy-specific questions, the firm moves to the configured option with the same test set. Custom work stays off the table unless both fail for reasons only custom work would fix.
Whatever the firm chooses, the trial needs a threshold, an owner, and a stop condition, or it will drift the way stalled AI pilots do. Build-versus-buy recommendations are part of Cleland & Co.'s AI Strategic Advisor engagement, alongside a scored use-case roadmap and vendor evaluation.
