Phase 2: Discovery & AI Product Strategy · 45 min · OpenAI API · Anthropic API · Google Gemini API
Build vs Buy vs Fine-Tune
Prompting is renting, fine-tuning is a mortgage, and self-hosting is building the house. Know which one your opportunity can actually afford.
Hiring signal: AI PM total comp at large tech/AI-native companies runs $214k-$427k in 2026, and the technical bar behind that number is API/integration literacy plus a real cost model — not a vendor preference. Frontier lab hiring managers explicitly test whether a PM can get into the details on cost tradeoffs across sourcing options, and a documented TCO comparison is the artifact that proves it.
What you will learn
- Map the vendor landscape across frontier API providers and open-weight self-hosting options
- Distinguish build, buy, and fine-tune as sourcing decisions rather than technical implementation details
- Build a total cost of ownership model spanning inference, hosting, fine-tuning, and engineering time
- Recommend a sourcing path for a given opportunity and defend it with a cost comparison, not just a preference
The Problem
The policy-document lookup opportunity from the last lesson gets approved. Now someone has to decide how to actually source the AI capability. The engineering lead wants to fine-tune an open-weight model on the company's policy corpus, arguing it'll be cheaper at scale and give more control. The CTO wants to just call the Anthropic API with a well-built RAG pipeline, arguing speed to market matters more than marginal cost right now. A vendor cold-emails the VP of Product pitching a fully managed "AI knowledge base" SaaS product that does the whole thing for a flat monthly fee.
All three are legitimate options. None of them is obviously right without a cost model. This is where a lot of AI product work goes wrong: the decision gets made on whoever argued most persuasively in the room, or on which option the loudest engineer personally wants to work on, instead of on a total cost of ownership comparison that accounts for what actually changes at 10x usage.
The build-vs-buy-vs-fine-tune decision is really three separate axes collapsed into one conversation, and untangling them is the first job:
- Where does the capability come from? A frontier API (OpenAI, Anthropic, Google), an open-weight model you host yourself (Llama, Mistral, DeepSeek, Qwen), or a fully managed third-party SaaS product.
- How do you adapt it to your problem? Prompting alone, retrieval-augmented generation (grounding responses in your own data without touching model weights), or fine-tuning (actually updating weights on your own examples).
- Who owns the operational burden? Do you run inference infrastructure, or does a vendor?
The Vendor Landscape
The frontier API providers — OpenAI, Anthropic, Google — sell access to state-of-the-art models per token, with no infrastructure to manage. You get frequent model upgrades, strong general reasoning, and predictable per-token pricing you can find on their public pricing pages. The tradeoff is per-token cost at scale, less control over the exact model version and its update cadence, and data-handling terms you have to read carefully if you're in a regulated industry.
Open-weight models — Llama, Mistral, Qwen, DeepSeek, and others — flip that tradeoff. You self-host (on your own GPUs or a cloud GPU rental), which means no per-token API fee, full control over the model version (it never silently changes under you), and the ability to fine-tune freely. The cost shifts from "pay per token" to "pay for GPU capacity whether you're using it or not," plus the engineering time to actually run inference infrastructure reliably. This is a real fixed-cost-vs-variable-cost tradeoff, not just a technical one — it only pays off once usage is high and predictable enough that the fixed GPU cost beats the variable per-token cost.
A fully managed vendor SaaS product sits on top of either of these — it's "buy" in the purest sense. You give up the most control and the most differentiation (a competitor can buy the exact same product), but you get the fastest time to a working feature and someone else owns the reliability and security burden.
Fine-tuning is a sourcing decision, not a capability upgrade
Product teams often treat fine-tuning as "make the model smarter," but the mechanism is narrower and more specific: fine-tuning changes how a model responds to your specific input distribution and desired output format, using examples you provide. It rarely teaches a model new knowledge it didn't already have — that's what retrieval (RAG) is for. If the goal is "answer questions about our specific, changing policy documents," RAG is almost always the right tool, because fine-tuning bakes a knowledge snapshot into the weights that goes stale the moment a policy changes, and re-fine-tuning on every update is far more expensive than re-indexing a document store. Fine-tuning earns its cost when the goal is a consistent format, tone, or behavior pattern across thousands of examples — not when the goal is "know about our current data."
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers Total Cost of Ownership: What Actually Changes at Scale, Making the Recommendation, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy