Build vs Buy vs API: How to Make AI Platform Decisions in 2026
Fine tune a model, call a frontier API, or buy a vertical tool? A real decision framework covering moats, switching costs, and a worked ERP shop example.
Every real AI project eventually reaches the same practical question: should we build this ourselves using a frontier model's API, buy an existing vertical tool that already does most of what we need, or fine tune a model on our own data. This is not a technical question first, it is a strategy question wearing technical clothes, and candidates who answer it well are demonstrating genuine product judgment, not just AI knowledge.
Most candidates default to whichever option they personally find most interesting to build, which is exactly backwards. The right answer depends on whether the capability is actually core to what makes the business different, how much real data volume is available, and how much switching cost a decision locks the company into later. This guide gives you a real framework for reasoning through it.
By the end of this guide, you will have a real decision framework for choosing between building with a frontier API, buying a vertical tool, or fine tuning a model, covering when each option actually makes sense.
You will understand the concept of a competitive moat as it applies to AI features specifically, why switching costs matter more than most people initially consider, and you will have a worked example applying the framework to a real ERP heavy procurement context.
Why this reasoning has become a distinct interview topic
A team that reflexively builds everything in house, even capabilities a vertical tool already handles well, wastes real engineering time maintaining something that added no actual competitive advantage. A team that reflexively buys everything, even the specific capability that is genuinely core to their business, ends up dependent on a vendor for the one thing that was supposed to differentiate them. Both mistakes are common, and both trace back to skipping the same underlying question: is this capability actually core to what makes us different, or is it a commodity capability other tools already solve well.
Employers hiring for AI product and strategy roles specifically probe this because getting it wrong is expensive in a way that is hard to reverse quickly. A wrongly built system represents months of engineering time that could have been spent elsewhere. A wrongly bought system can create a dependency that is genuinely difficult and costly to unwind later. This makes build versus buy versus API reasoning a real, high stakes strategic skill, not an implementation detail to be decided casually.
There is also a career specific reason this matters: candidates who can reason clearly about this tend to get pulled into decisions well above their formal seniority, because a leadership team facing a genuine build versus buy question wants input from anyone who can reason about it clearly, regardless of title. Demonstrating this skill early is one of the more reliable ways a candidate ends up in the room for decisions that would otherwise be reserved for more senior people.
The moat question: what actually needs to be built in house
A competitive moat, in this context, is a capability that genuinely differentiates a business from its competitors, something that creates real, durable advantage rather than simply matching what everyone else already has access to. The core question for any AI capability: is this the thing that actually makes us different, or is it table stakes work that a vertical tool or a general API can handle just as well.
Spend categorization, for most companies, is not a moat. Nearly every company in a given industry needs it, several vertical tools already do it reasonably well, and doing it slightly better than a competitor rarely changes competitive outcomes on its own. A proprietary supplier negotiation strategy built on years of a specific company's own relationship and pricing data, by contrast, genuinely can be a moat, something worth building and protecting in house rather than handing to an outside vendor.
Switching costs: the factor most people underweight
Beyond the moat question, a second real factor deserves deliberate weight: how hard would it be to leave this decision later if it turns out to be wrong. A vertical tool deeply integrated into a company's core data and workflows can become genuinely difficult to migrate away from, not because the tool is bad, but because untangling years of dependency is real, costly work. Calling a frontier model's API for a specific task, by contrast, is comparatively easy to swap for a different provider or model later, since the integration surface is typically much smaller and more standardized.
This does not mean vertical tools are always the wrong choice, sometimes the switching cost is genuinely worth accepting for the speed and quality a specialized tool provides. It means switching cost should be a deliberate, named factor in the decision, not a surprise discovered two years later when the company wants to change course and finds it cannot easily do so.
A worked example: an Oracle ERP shop making two different calls
Consider a mid sized manufacturer running its procurement operations on Oracle ERP, evaluating two separate AI capabilities at the same time, and reaching two different, both correct, conclusions.
Spend categorization and duplicate invoice detection: applying the moat check, this is not a differentiator, nearly every company in the industry needs the same capability, and several vertical procurement tools already handle it well, with real, current data connections to common ERP systems. The team buys a vertical tool rather than building this in house, correctly treating it as table stakes work not worth the engineering investment to build and maintain themselves.
Supplier risk scoring using the company's own historical relationship and performance data: this data genuinely does not exist anywhere else, since it reflects years of this specific company's own supplier interactions, and a generic vertical tool cannot replicate an advantage built on proprietary history. The team builds this themselves using Claude Code connected via MCP style connections directly to their own Oracle data, correctly treating this as a genuine moat worth the real engineering investment.
Same company, same general technology stack, two different correct decisions, because the moat question was applied honestly to each capability separately rather than adopting one blanket build or buy policy for everything.
The decision framework at a glance
Four questions, weighed together, not in isolation.
| Question | Leans toward Buy | Leans toward Build |
|---|---|---|
| Is this core to our differentiation? | No, it's table stakes work | Yes, it's our real advantage |
| Do we have unique data others lack? | No, data is common across the industry | Yes, proprietary history or relationships |
| How costly is a wrong choice to reverse? | Vertical tool switching cost is acceptable | Building keeps us in full control |
| Does a vertical tool already do this well? | Yes, tested and proven for this task | No, nothing fits our specific need |
Questions this topic usually raises
Expand each one.
Fine tuning, adapting a model specifically to a narrow, repeated task using real examples, tends to make sense when a task is genuinely high volume and specific enough that a general frontier model's broader capability is not the limiting factor, and when there is enough real, high quality example data to fine tune on. Without meaningful data volume, fine tuning rarely outperforms simply calling a strong frontier API with good prompting.
Yes, and it should be. Build versus buy versus API is not a permanent, one time decision. As a company's own capability, competitive position, and available tools change, a previously correct decision can become the wrong one, which is exactly why switching cost matters as a factor from the start.
When honestly uncertain, buying or using a frontier API directly is usually the lower risk default, since it avoids over investing engineering effort in a capability that might not actually be a differentiator. A team can always build later once the moat becomes clearer with more evidence.
Practice these interview questions
Build versus buy is a classic strategy question made sharper by how fast AI capability and vendor options change. Work through your own answer first, then compare with the sample.
Why they're asking: They want the actual decision criterion, strategic differentiation versus a commodity problem, not a generic pros-and-cons list.
Hit these points:
- Name the first question: is this capability actually core to what makes the business differentiated
- Name the buy case: a common, well-solved problem other companies have already built good solutions for
- Say buying or using an API is usually faster and cheaper than reinventing something that already exists well
- Name the build case: something genuinely core to the specific edge that a generic vendor solution can't capture
Sample answer:
- The first question: "I'd start by asking whether this capability is actually core to what makes the business differentiated, or whether it's a common, well-solved problem others have already built good solutions for."
- The buy case: "If it's the latter, buying or using an API is usually faster and cheaper than reinventing something that already exists well."
- The build case: "If it's genuinely core to our specific edge, something a generic vendor solution can't capture, building in-house is more likely worth the extra time and cost."
Remember it as: Core to the edge, build it. Commodity problem, buy it.
Why they're asking: They want concrete risks beyond initial build time, ongoing maintenance and opportunity cost specifically.
Hit these points:
- Name the real cost beyond the initial build: ongoing maintenance to keep it updated as the AI landscape moves fast
- Name the opportunity cost: engineering time that could have gone toward something more differentiated
- Name the competitive risk: a vendor with a dedicated team focused only on that capability tends to out-iterate an internal team
- Explain why the internal team loses that race: it's one part of a broader roadmap for them, not the sole focus
Sample answer:
- The hidden cost: "The real cost isn't just the initial build time, it's the ongoing maintenance burden afterward, keeping it updated as the underlying AI landscape moves fast."
- The opportunity cost: "There's also the opportunity cost of the engineering time that could have gone toward something more differentiated for the business."
- The competitive risk: "A vendor with a dedicated team focused only on that one capability will often out-iterate an internal team who's building it as one part of a broader roadmap."
Remember it as: You're not just building it once, you're maintaining it forever.
Why they're asking: They want concrete dependency risks named specifically: pricing, outages, deprecation, not a vague 'vendor risk' answer.
Hit these points:
- Name three specific risks: pricing changes, service outages, and deprecation of the exact capability you rely on
- Say this directly affects the product with limited control on your end
- Name when building instead makes sense: a genuinely core, differentiating capability, even at higher initial cost
- State the reason for that tradeoff: avoiding being at the mercy of someone else's roadmap and pricing for something central
Sample answer:
- The dependency risk: "You're taking on dependency risk, if the vendor changes pricing, has an outage, or deprecates the exact capability you're relying on, that directly affects your product with limited control on your end."
- When to build instead: "For a genuinely core, differentiating capability, that risk might be worth building in-house instead, even at higher initial cost."
- Why: "Specifically to avoid being at the mercy of someone else's roadmap and pricing decisions for something central to the business."
Remember it as: Pricing, outages, deprecation: three ways a vendor can move the ground under you.
9 of 12 answers are locked. Any paid plan unlocks every question like these, and Foundation adds the full course catalogue.