Last reviewed: July 2026
The question is never "can we build it". You can. A competent team with a provider API can put a working AI feature in front of users in a fortnight. That is exactly the problem. Because it is cheap to start, teams start, and twelve months later they own a system that a vendor now sells as a checkbox for less than the salary of the engineer maintaining it.
The real question is whether this capability will ever be a durable advantage. If the answer is no, every engineer-month you spend on it is a month you did not spend on something that is.
The default, stated plainly: buy the commodity, build the differentiator. And be honest about where the differentiator actually lives. Almost nothing about the model layer is a differentiator. The frontier models are available to your competitors at the same price, on the same day, through the same three lines of code. What might be a differentiator is your proprietary data, your eval suite (because it encodes what "good" means in your domain, and nobody else has it), and the way the capability is woven into a workflow your users already live in.
This page is the business decision: buy a product, build on a provider's API, or invest in your own weights. The technical choice between prompting, RAG, and fine-tuning as engineering techniques is covered in Fine-tuning vs RAG vs prompting. Read that one for the mechanics. This one is about where the money and the year go.
1. Buy a finished product. A vendor's AI support tool, an AI code review product, an AI meeting assistant. You get a working thing, a roadmap you do not control, and someone else's opinion about what good looks like. The pitch is time to value, and the pitch is usually true. The catch is specific to AI products: the vendor's model choice, their prompts, their retrieval, and their threshold for "confident enough to act without a human" are all sealed behind the UI. You cannot inspect why it answered the way it did, you cannot tune the precision-recall trade-off to match your own tolerance for a wrong answer reaching a customer, and when the behaviour drifts because they swapped the model underneath, you find out from your users rather than from a release note.
2. Build on a provider's API. Your product, their model. This is the common case and the correct answer far more often than teams expect. You own the prompts, the retrieval, the guardrails, the evals, the UX, and the data flow. You rent the hard part. The model becomes a dependency you can swap, which is the whole point.
3. Fine-tune an open or provider model. Your weights, their base. You are now in the business of maintaining a model: a training pipeline, a dataset that must stay clean, an eval suite that must catch regression, and a standing obligation to redo the work when the base model moves. Sometimes worth it. Usually premature.
4. Train from scratch. Essentially never correct outside a foundation lab or a genuinely unique data domain at very large scale. Three reasons, said bluntly. The cost is enormous and it is capital, not opex. The result is behind the frontier within months, because the labs ship on a cadence you cannot match. And the talent that can actually do it is the scarcest in the market, which means you are not just paying for it, you are competing for it against organisations whose entire purpose is that work.
If you are not sure which of the four you are in, you are in option 2.
flowchart TD
A["Start"] --> B{"Differentiator or table stakes?"}
B -->|"Table stakes"| C{"Does a mature product exist?"}
C -->|"Yes"| D["Buy the product"]
C -->|"No"| E["Build on an API"]
B -->|"Differentiator"| F{"Proprietary data or workflow others cannot copy?"}
F -->|"No"| E
F -->|"Yes"| G{"Prompting plus RAG hits the quality bar?"}
G -->|"Yes"| H["Build on an API and stop"]
G -->|"No"| I{"Thousands of good examples and a team to maintain a model?"}
I -->|"No"| J["Fix the data problem first"]
I -->|"Yes"| K["Fine-tune"]
K -.->|"Essentially never"| L["Train from scratch"]
Walk it once. The first fork is the only one that is really a strategy question, and it is the one teams skip. Table stakes means your customers expect it, your competitors have it, and having it better does not win you anything. AI-generated meeting summaries are table stakes. If a mature product exists for a table-stakes capability, buy it, because winning at it is not available to you. If no mature product exists yet, build the thinnest thing on an API that clears the bar, and expect to replace it with a bought product later. That is fine. Plan for it.
If it is a differentiator, the next fork catches the most common self-deception. Teams assume that because the feature is differentiating, the model must be too. It almost never is. Ask what a competitor could not copy in a quarter. If the honest answer is "nothing, they just have not bothered", the differentiator is your execution and your product, not your weights, and you build on an API. Only if you have data or a workflow that genuinely cannot be replicated does the model layer come into play at all.
Then the quality gate. Prompting plus RAG is the cheapest thing that could possibly work, and it works far more often than the fine-tuning discourse suggests. If it hits the bar, stop. Ship. The dotted line to "train from scratch" is dotted on purpose: it is reachable, and you should treat reaching it as evidence you have made an error somewhere upstream.
| Buy a product | Build on an API | Fine-tune | Train from scratch | |
|---|---|---|---|---|
| Time to first value | Days to weeks, dominated by procurement and integration, not the tool | Days to a demo, weeks to production quality | Months, and most of it is dataset work before any training runs | Quarters to years |
| Upfront cost | Low engineering, real procurement and security review | Low, a spike costs a fortnight | Moderate to high, front-loaded into data collection and labelling | Enormous, and it is capital |
| Ongoing cost shape | Per-seat or usage licence, predictable, grows with headcount or volume | Per-token, grows with usage, drops when providers cut prices or you switch models | Inference cost per call can be much lower, but a standing training and eval cost never goes away | Everything, forever |
| Engineering headcount needed | Small integration team, plus an owner nobody remembers to name | Small product team, no ML specialists required | Needs someone who genuinely owns modelling, plus data engineering | A research organisation |
| Data required | None beyond configuration | None to start, retrieval corpus if you add RAG | Thousands of high-quality, consistently labelled examples | Web-scale corpora and the licences to use them |
| Quality ceiling | The vendor's ceiling, on the vendor's timeline | The frontier, and it rises for free when providers ship | Can exceed a general model on your narrow task, will lag it on everything else | Below the frontier within months |
| Differentiation | None, your competitor buys the same tool | Comes from your data, evals, and workflow, not the model | Real but narrow, and it decays as base models improve | Theoretically total, practically negative |
| Switching cost | Moderate, contract plus the integration you rebuild | Low if you kept a seam, high if you scattered provider calls through the codebase | High, you rebuild the pipeline and revalidate | Total |
| Who owns quality | The vendor claims to, you get the complaints | You, entirely, which is uncomfortable and correct | You, entirely, including regressions you caused | You |
| Maintenance burden | Upgrades, contract renewals, chasing the vendor on your edge cases | Prompt and eval upkeep, model version migrations | All of the above plus retraining every time the base moves | Unbounded |
| Fails when | Your workflow is not the workflow the vendor designed for | The capability was genuinely commodity and you rebuilt it anyway | The base model improves past your fine-tune and nobody notices for a quarter | Always, outside a lab |
The eval suite you must build regardless. This is not optional even when you buy. A vendor's benchmark tells you the product works on the vendor's traffic. It tells you nothing about yours. You need a held-out set of your own real cases, scored the way your business defines correct, or you cannot tell whether the thing you bought is working, and you certainly cannot tell when it stops. Budget it in every column of the table.
Integration and workflow work. In a "buy" this is usually the majority of the effort, and it is the part the sales cycle never discusses. The ordinary plumbing is real enough, but the work that surprises people is the work that exists because the thing is probabilistic: deciding what confidence level lets the system act without a human, building the review queue for everything below that line, designing what the user sees when the model is confidently wrong, and capturing the corrections your reviewers make in a form your eval suite can actually consume later. A tool that answers is a demo. A tool that knows when not to answer, and routes that case somewhere useful, is a product, and you build that half yourself no matter whose logo is on the licence. The licence is the cheap part.
The data cleanup that RAG or fine-tuning exposes. Every retrieval or fine-tuning project turns into a data project about three weeks in, because that is when you discover your documentation contradicts itself and your labels were applied by four people with four definitions. This is one of the reliable ways these projects go sideways. See Common failure modes.
The maintenance of a fine-tune when the base model moves on. Fine-tuning vs RAG vs prompting explains why this is a standing obligation rather than a one-off. What matters here is the shape of the cost: it is a recurring tax with no line item, which means it never appears in the business case and always appears in the roadmap.
The vendor's model changes becoming your incident. You asked for the feature. It is on their board, behind their bigger customers. That much is true of any supplier. What is particular to an AI vendor is the change you did not ask for and cannot see: they swap or upgrade the model under their product, the behaviour your team spent a quarter calibrating around shifts, and nothing in the release notes says "we changed what the model considers a refund request". When ordinary software changes underneath you, it breaks an interface and your tests go red. When this changes underneath you, it moves a distribution, stays green, and is detectable only by your own evals running continuously against their output. Your product plan is downstream of a company whose priorities are not yours, and so is your quality baseline.
The migration cost you did not price when you picked an orchestration framework. These frameworks become load-bearing very quickly, and this layer churns faster than almost anything else in your stack, because it is chasing a model capability surface that will not hold still. The abstraction over "a provider call" holds right up to the moment you need a provider-specific feature it has not wrapped yet, and then the seam you thought you had turns out to be somebody else's opinion about how tool calling should work. The one you adopted in an afternoon becomes the thing you cannot remove in a quarter.
The opportunity cost of the engineers, measured against a commoditisation clock. This is the largest number on the page and it never appears in the business case. Four engineers for a year on a capability a vendor will commoditise is not a cost of that project. It is the roadmap you did not ship. What makes this sharper here than in ordinary build-versus-buy is how fast the clock runs: the prompt and retrieval work that took your team a year can arrive as a provider's native feature or as a checkbox in a product you already pay for, and it can arrive on an announcement day you had no visibility into. Price the year against that risk, not against the invoice.
Illustrative only. The assumptions are made up to show the shape of the arithmetic, not to give you numbers.
Capability: AI-assisted support triage. Incoming tickets are classified, routed, and given a draft response. Horizon: 12 months. Assumption: you have an existing ticketing system, a support team of moderate size, and no ML specialists.
| Buy a product | Build on an API | |
|---|---|---|
| Licence or API cost | Per-seat, predictable, scales with support headcount | Per-token, small at pilot volume, grows with ticket volume, falls as providers cut prices |
| Integration effort | 2-4 engineer-months, mostly identity, data flow, and taxonomy mismatch | 3-6 engineer-months, including retrieval over your help centre and the routing logic |
| Ongoing maintenance | 0.5-1 engineer-month per quarter, upgrades and vendor chasing | 1-2 engineer-months per quarter, prompt and eval upkeep, model migrations |
| Time to first value | Weeks, gated by procurement and security review | Weeks to a pilot, a quarter to trusted production behaviour |
| Quality you can actually reach | The vendor's ceiling on generic triage, weak on your product-specific edge cases | Whatever your evals and retrieval corpus support, which is higher on your specifics if you do the data work |
| Eval suite | 1-2 engineer-months. Required in both columns. |
How to read it. Compare the engineer-month rows first, then the licence row, then ask whether the quality gap on your specific edge cases is worth the difference. If your tickets look like everyone's tickets, the vendor wins on time and the difference in ceiling is noise. If a third of your volume is about your own product's peculiarities, the vendor's ceiling is a real constraint and the build path buys you a higher one.
The arithmetic that decides this is almost always engineer-months, not the invoice. Teams get it backwards because the invoice is visible, it arrives with a number on it, and someone in finance asks about it. The engineer-months are invisible. They are absorbed into a team's capacity and never reconciled against the plan they displaced. A licence that looks expensive next to zero looks cheap next to six engineer-months of integration plus four per year of maintenance, forever. Price the people, or you are not doing the comparison.
The four cases where fine-tuning is the right technique, and the caveat that dissolves each one, are in Fine-tuning vs RAG vs prompting. Work through them there first, because most candidate cases die on the caveat rather than on the business question.
Assume all four survive contact with your evals. The question is still open, and this is the counterweight that settles most of these conversations: if you cannot name the person who maintains this model in 18 months, you are not ready to fine-tune. Not the team. The person. A fine-tune is a standing commitment, and unowned commitments rot silently.
Rank the options by the cost of changing your mind.
| Option | Cost to reverse |
|---|---|
| Build on an API, behind your own seam | Low. Swap the model, keep everything else. |
| Buy a product | Moderate. Contract term plus rebuilding the integration. |
| Build on an API with provider calls scattered everywhere | High. You wrote a migration project and did not notice. |
| Fine-tune | High. Pipeline, dataset, revalidation. |
| Train from scratch | Total. |
The strategic rule: at high uncertainty, pay for reversibility. Early in a capability's life you do not know what good looks like, what it costs, or whether users want it. That is exactly when you should refuse to make expensive commitments. Building on an API behind your own interface keeps four doors open: change provider, change model size, drop in a fine-tune later, or delete the whole thing. A fine-tune closes two. A from-scratch model closes all of them.
For the exit-cost thinking in detail, see Vendor and model selection. Write the reasoning down using Model selection decision record, because the decision that is not recorded gets re-argued every quarter by people who were not there.
- Write the problem and the quality bar. One page. What the capability does, and the number or judgement that means it works. The bar has to be stated as a rate rather than a promise, because you are specifying a system that will be wrong some of the time by construction: what fraction wrong you accept, on which classes of case, and what happens to the ones it gets wrong. "Accurate" is not a bar. Something shaped like "routes the large majority of tickets correctly, never auto-sends on a billing dispute, escalates anything under threshold to a human" is a bar, because each clause can be scored. If you cannot state it, you cannot compare options, because every option looks fine against no bar.
- Check whether a product exists, and pilot it against your own evals. Not their demo. Your held-out cases. This is the fastest way to find the vendor's ceiling on your traffic.
- Run a two-week spike on the API path. Prompting plus retrieval, thrown together, scored on the same eval set. Two weeks is enough to know whether the bar is reachable and nowhere near enough to get attached.
- Price both in engineer-months. Integration, evals, maintenance per quarter, and the migration you will eventually do. Put the licence in a separate row so it stops dominating the conversation by being the only number.
- Write the decision record, including the trigger that would reverse it. "We buy until our edge-case volume exceeds X" or "we build until a product clears our eval suite". A decision without a reversal trigger is a decision nobody will revisit.
For running the work once you have decided, see AI project management.
- If a vendor shipped this exact capability next quarter for a modest licence, would we regret building it? If yes, do not build it.
- What can we do here that a competitor with the same API access cannot? If the answer is nothing, the model is not your moat and the build is not strategic.
- Who owns the eval suite, and does it exist yet? If it does not, none of the options are safe, because you cannot tell any of them apart.
- What is the total engineer-months over 12 months, including maintenance, and what does that displace on the roadmap?
- If this is wrong, what does it cost to undo, and when would we find out?
"Would you build or buy this" is a standard strategy question for engineering manager roles, and it is a filter. The weak answer picks a side and argues features. The strong answer refuses the framing for a moment and asks the prior question: is this capability a differentiator for us, or table stakes? Then it prices the options in engineer-months rather than licences, names the eval suite as a cost that appears in every column, and closes with the reversal trigger. Interviewers are listening for whether you know that the invoice is the small number and the team's year is the big one.
Next: Vendor and model selection
Related: Fine-tuning vs RAG vs prompting | Deployment options | Model selection decision record