Build vs Buy for AI: A Framework That Survives the Demo
On this page
TL;DR: The build-vs-buy question for AI is usually framed as two options, and that framing causes most of the bad decisions. There are three: buy an off-the-shelf product, assemble a solution on top of a frontier model’s API, or build something genuinely custom. Buying wins for commodity workflows, which is most workflows. Assembling wins when the value comes from your data and your process but the intelligence can be rented. Building wins only when AI is your product or your moat. The discipline is in admitting which case you are actually in, because everyone believes their workflow is special, and vendors of both consulting and software are happy to agree.
The three options, defined honestly
Buy means adopting a finished product: a general-purpose assistant like ChatGPT or Claude, an embedded suite assistant, or a specialized vertical tool for support, contracts, or code. You get speed, a roadmap someone else funds, and per-seat or usage pricing. You give up fit: the product does what its median customer needs.
Assemble means renting the intelligence (a frontier large language model via API) and building the thin layer that makes it yours: connecting it to your documents with retrieval-augmented generation, encoding your process in prompts and workflows, integrating with your systems. No model training, no ML team, but real software work: someone must own evaluation, monitoring, and updates.
Build means creating substantial custom capability: fine-tuning or training models, building proprietary pipelines, owning the full stack. This is a product-engineering commitment with everything that implies: specialized talent, evaluation infrastructure, and a maintenance tail that outlives everyone’s initial enthusiasm.
Most published advice collapses assemble into build and then argues buy-vs-build as if the middle did not exist. In practice the middle is where most successful company-specific AI lives, and recognizing it changes the economics of the whole decision.
Comparison table
| Dimension | Buy off-the-shelf | Assemble on model APIs | Build custom |
|---|---|---|---|
| Time to first value | Days to weeks | Weeks to months | Months to a year or more |
| Upfront cost | Low | Moderate | High |
| Ongoing cost shape | Per seat or per use, grows with adoption | API usage plus engineering ownership | Engineering ownership dominates; usage costs vary |
| Fit to your workflow | Median-customer fit | High: your data, your process | Highest, if executed well |
| Differentiation created | None (competitors buy the same tool) | Some, from data and workflow encoding | Potentially durable |
| Talent required | Admin and adoption ownership | A capable software team | Specialized AI engineering |
| Maintenance burden | Vendor’s problem | Yours, moderate (prompts, evals, model updates) | Yours, heavy |
| Key risk | Paying premium for thin wrappers; vendor lock-in | Underestimating the ownership work | Building what the market commoditizes next quarter |
| Exit cost | Low to moderate | Moderate | High (sunk investment) |
When to buy
The workflow is commodity. Meeting notes, email drafting, document summarization, generic coding assistance, transcription: these are solved repeatedly by well-funded vendors, and their median-customer product is better than what you would build, this year and next. Buying here is not a compromise; it is correct resource allocation. Our use case library covers dozens of these.
Speed matters more than fit. A bought tool delivers value while a built one is still in planning. When the goal is organizational learning (getting your people fluent with AI, discovering which workflows matter), buying a general-purpose assistant is the cheapest possible tuition. The adoption roadmap covers this sequencing.
You lack a team to own software. Custom AI without an owner degrades quietly: models get deprecated, prompts drift out of tune, quality erodes with nobody watching. If there is no engineering capacity with durable responsibility, the vendor’s maintenance team is a feature you are rationally paying for.
The buying discipline: apply the evaluation framework so you screen data terms and integration honestly, and run the thin-wrapper test. If a specialized product’s output matches what your sanctioned assistant produces with a good prompt, you are buying a subscription to a prompt.
When to assemble
The value lives in your data. An assistant that answers from your policies, your product docs, your past proposals is categorically more useful than a generic one, and retrieval over your content is a standard, well-trodden pattern that does not require training anything. Internal knowledge assistants are the canonical case.
The value lives in your process. When the win is encoding how your company qualifies leads, triages tickets, or reviews contracts, the intelligence is rentable but the process encoding is yours. A model API plus workflow logic plus your rubric captures it; no off-the-shelf product will match a process it has never seen.
Vendor pricing breaks at your volume. Per-seat or per-task pricing that is fine at pilot scale can dwarf raw API costs at production volume. When usage is high and the wrapper is thin, owning the thin layer yourself changes the unit economics. Do this math with real numbers from a pilot, not projections.
You need control a product will not give. Specific model choice, deployment constraints, audit and logging requirements, custom guardrails: assembling gives you the dials that packaged products hide.
The assembling discipline: treat it as software, not a script. Budget for an evaluation suite before launch, monitoring after, and a named owner. Assembled solutions fail not in the demo but in month four, when the model version changes and nobody notices the quality drop until users stop trusting it.
When to build
AI is the product. If customers pay you for an AI capability, renting undifferentiated intelligence and owning nothing defensible is a strategy problem. Here, deeper investment (custom pipelines, fine-tuning, proprietary evaluation) is the moat-digging work.
A vendor structurally cannot serve you. Genuine cases exist: extreme data-sensitivity postures requiring specific deployment models, domains where no product plus configuration gets close, or integration depth no vendor will offer. Verify by exhausting assemble first; “we tried a demo and it missed” is not exhausting assemble.
You have proven economics at scale. The strongest build cases are usually promotions: an assembled solution that proved value, hit vendor or API limits, and now justifies deeper ownership with real usage data behind the business case.
The building discipline: assume the frontier keeps moving. The most expensive AI mistake of recent years has been building capabilities that foundation models absorbed a quarter later. Build the parts that get more valuable as models improve (your data pipelines, your evaluation, your workflow integration), not the parts racing the labs.
The honest verdict
Default to buy, graduate to assemble, and treat build as a deliberate strategic act rather than a procurement outcome. In practice, a healthy mid-sized company portfolio looks like: a sanctioned general assistant for everyone, a handful of bought specialized tools that passed the thin-wrapper test, one or two assembled solutions where its data or process is genuinely distinctive, and zero fully custom builds unless AI is the business. Measure all of it: Measuring AI ROI covers how, and the same measurement that justifies an assembled solution is what later justifies (or kills) a build.
The question that cuts through most debates: if a competitor bought the same tool tomorrow, would we have lost anything? If no, buy it. If yes, and the difference is your data or process, assemble. If yes, and the difference is the capability itself, you have a build case, and it deserves a real business plan, not a hackathon.
Not sure where your company stands? Take the free AI-Readiness Assessment.
FAQ
When is building custom AI worth it? When at least one of three conditions holds: the AI capability is part of your product or a durable competitive advantage; no vendor serves your workflow without contortions that destroy the value; or your volume and unit economics make per-seat or per-usage vendor pricing clearly worse than owning the pipeline. If none apply, buy or assemble. A fourth pseudo-condition, data too sensitive to share with any vendor, is real but rarer than claimed, since major vendors now offer strong contractual and deployment options.
What does it actually cost to build a custom AI application? The build is the visible cost; the ownership is the real one. A custom AI application needs evaluation suites, monitoring, prompt and model updates as providers deprecate versions, security reviews, and someone on call when quality drifts. Teams routinely find ongoing ownership costs rival the initial build over a couple of years. If your plan has no line item for maintenance and evaluation, the plan is wrong, and the comparison against a vendor subscription is fiction.
What is the middle option between building and buying? Assembling: using a frontier model through its API plus standard patterns like retrieval-augmented generation to make it work on your data and workflows, without training your own model. It captures most of the customization benefit at a fraction of build cost, and it is where the majority of successful custom-ish business AI actually lives. The tradeoff is that you still own evaluation, monitoring, and maintenance, just less of it.
How do we avoid buying a thin wrapper? Test whether your general-purpose assistant with a well-crafted prompt matches the product’s output on your tasks. Ask the vendor what exists beyond the model call: proprietary data, deep integrations, workflow tooling, evaluation and guardrails. If the answer is a system prompt and a nice interface, you are being asked to pay a recurring subscription for something your team could replicate in days.
Should a small company without engineers ever build? Fully custom, almost never. But assembling has become accessible: many integration platforms and vendor features let non-specialist teams connect a model to their documents and tools with configuration rather than code. A small company’s best path is usually buy for commodity needs, use those configuration surfaces for light customization, and revisit building only if AI becomes central to the product it sells.
Frequently asked questions
When is building custom AI worth it?
When at least one of three conditions holds: the AI capability is part of your product or a durable competitive advantage; no vendor serves your workflow without contortions that destroy the value; or your volume and unit economics make per-seat or per-usage vendor pricing clearly worse than owning the pipeline. If none apply, buy or assemble. A fourth pseudo-condition, data too sensitive to share with any vendor, is real but rarer than claimed, since major vendors now offer strong contractual and deployment options.
What does it actually cost to build a custom AI application?
The build is the visible cost; the ownership is the real one. A custom AI application needs evaluation suites, monitoring, prompt and model updates as providers deprecate versions, security reviews, and someone on call when quality drifts. Teams routinely find ongoing ownership costs rival the initial build over a couple of years. If your plan has no line item for maintenance and evaluation, the plan is wrong, and the comparison against a vendor subscription is fiction.
What is the middle option between building and buying?
Assembling: using a frontier model through its API plus standard patterns like retrieval-augmented generation to make it work on your data and workflows, without training your own model. It captures most of the customization benefit at a fraction of build cost, and it is where the majority of successful custom-ish business AI actually lives. The tradeoff is that you still own evaluation, monitoring, and maintenance, just less of it.
How do we avoid buying a thin wrapper?
Test whether your general-purpose assistant with a well-crafted prompt matches the product's output on your tasks. Ask the vendor what exists beyond the model call: proprietary data, deep integrations, workflow tooling, evaluation and guardrails. If the answer is a system prompt and a nice interface, you are being asked to pay a recurring subscription for something your team could replicate in days.
Should a small company without engineers ever build?
Fully custom, almost never. But assembling has become accessible: many integration platforms and vendor features let non-specialist teams connect a model to their documents and tools with configuration rather than code. A small company's best path is usually buy for commodity needs, use those configuration surfaces for light customization, and revisit building only if AI becomes central to the product it sells.