PreviewYou're previewing CTO AI Forge. Sign in to use it.Sign in
← All lessons
L5 · Expert: the AI-first engineering organization10 min read

Build vs buy vs fine-tune

AI has changed the economics of build-versus-buy twice: once for the AI capabilities you put in your product, and again for ordinary software, because coding agents make building cheaper.

Four common options for an AI capability

  1. Buy a SaaS product with AI built in: fastest time to value, least control, vendor lock-in risk.
  2. API model + your own application: you own the workflow, data handling and UX; the model is rented and swappable through a gateway.
  3. Open-weights model, self-hosted: maximum data control and no per-token fees; you pay in GPUs, operations and ML skills.
  4. Fine-tune (a hosted or open model): better fit for a narrow task or style; ongoing cost of data, training and re-training when base models improve.

How to decide

Score the options on cost, latency, quality on your eval set, security and data control, lock-in, and team skill, weight what matters for this use case, and test whether the winner holds when weights move. Then write the decision down as an ADR. The build-vs-buy matrix tool does exactly this.

Two cautions from experience

  • Training your own model is a large commitment. Bloomberg built BloombergGPT, a 50-billion-parameter model trained on a 363-billion-token dataset from Bloomberg's own financial data plus 345 billion tokens of general data (2023). Few organizations have that data, budget and team — and general models keep improving underneath you.
  • Retrieval often beats fine-tuning for knowledge. Research comparing the two found retrieval consistently outperformed unsupervised fine-tuning for injecting knowledge.

Building ordinary software instead of buying

Coding agents make it tempting to build ordinary software instead of buying it, and some organizations now do. Remember that building is cheap only at the start: maintenance, security, on-call and upgrades last for years.

What this means for the CTO

Make build-vs-buy a repeatable decision process, not a debate: the same criteria, weights agreed with product and finance, a sensitivity check, and an ADR that records why. Revisit decisions when prices, model quality or vendor terms change materially.

For "we could build this with agents" proposals, ask for the five-year cost of ownership — maintenance, security, support — not just the build effort.

Agree the criteria and weights with product and finance before scoring, so the matrix reflects shared priorities. And keep a list of decisions with review dates — the right answer in 2026 may be wrong a year later as models and prices change.

Real example

Bloomberg's research team described BloombergGPT (March 2023) as a 50-billion-parameter language model trained on a 363-billion-token dataset based on Bloomberg's own data sources, plus 345 billion tokens from general-purpose datasets, illustrating the data and compute scale behind building a domain model. Source: Wu et al. — BloombergGPT: A Large Language Model for Finance (arXiv 2303.17564, 2023) ↗

Use it

Quick check · 3 questions

  1. 1.Which option usually gives the most data control and no per-token fees?

  2. 2.What should a build-vs-buy decision record include?

  3. 3.What cost is most often forgotten when 'we can build it with agents'?

0 of 3 answered

Sources

Last reviewed 2026-10-22.