Concepts / Choosing Between Building and Buying AI Models

Choosing Between Building and Buying AI Models

Picking a technology for an AI product is rarely a one-time event.

  • Programming

Why a Good Decision Expires

Picking a technology for an AI product is rarely a one-time event. A team may choose to host its own model, or to pay a model provider, after a careful comparison. That choice can look excellent for months and then stop being excellent. This article follows that lifecycle. It looks at the outside forces that make such decisions expire: shifting prices and providers, government regulation of the resources AI depends on, and unresolved questions about who owns what a product is built from.

What do you think happens?

A team is deciding whether to build a model in-house or pay a model provider. They conclude that building in-house is cheaper, so they commit. Three months later, the model providers cut their prices in half. What is the state of the team's decision now?

  • The decision is still correct, because it was correct when made

  • The decision may now be the wrong choice and needs to be weighed again

  • The decision is automatically reversed by the providers

Reveal answer
Answer:

The decision may now be the wrong choice and needs to be weighed again.

The source's central point is that the best option today may become the worst option tomorrow. A sound decision was based on the prices and providers that existed when it was made. When those change, the comparison has to be done again, and the in-house option may have become the more expensive one.

Tracing One Decision Through Time

Follow the team from the scenario step by step. At launch, the team compares the cost of building in-house with the cost of paying a provider, and building wins. Nothing about that comparison was wrong. The problem is that the comparison used a snapshot of market prices. Once the providers cut prices, the snapshot was out of date, even though the team's reasoning was still careful.

Launch decisionBuilding is cheaperTeam commitsBuild in-houseThree months laterPrices unchanged in theplanProviders cut pricesCut in halfDecision questionedNeeds reviewbased ontime passesmarket shiftsinvalidates
How does a decision that was correct at launch turn into a poor one as prices and providers change over time?

The timeline shows the key point of this article. The decision was not made wrongly. It was made on the facts of its moment, and those facts moved. For that reason, each technology investment has to be treated as something that is checked again, not as a settled question.

Three Kinds of Outside Pressure

The source groups the pressures that expire a decision into three categories: changes in the market for model services, changes imposed by regulators, and open legal questions about intellectual property. These pressures differ in how hard they are to absorb. Some are a matter of routine engineering effort, while others can threaten the product itself. Keeping the three apart helps a team decide which pressures need a plan and which need an emergency response.

The Review Cycle for Each Investment

Because outside forces keep moving, the source describes a constant need for vigilance. The useful habit is a repeated review. At each review point, a team re-checks the same inputs that the original decision relied on, and then either keeps its current choice or switches. The loop below shows the steps that repeat each time.

Re-check pricesProviders and ratesRe-check providersWho offers the serviceRe-check regulationCompute and compliancerulesRe-check IP exposureLegal ground under themodelKeep, build, or buyDecide at this reviewthenthenthenthennext review
What steps repeat at each review point, and what triggers a switch from building to buying or the reverse?

The four checks are not a source-given procedure. They are a practical reading of the three pressure groups, with prices and providers combined under market change. What the source does establish is that each investment has to be weighed again, and the loop is one way to make that repetition concrete.

How a Restriction Reaches a Product

The source makes a sharp claim: compute availability can change overnight, because new laws put more restrictions on who can buy and sell compute resources. It points to the US October 2023 Executive Order as an example. The consequence is direct. If your GPU vendor is suddenly banned from selling GPUs to your country, the supply your product relies on can disappear without warning.

Vendor sells GPUsSupply to your countryVendor banned fromsellingNew law restricts salesProduct runs onsupplyNormal operationSupply disappearsWithout warningfeedsremoves
How does a regulatory change alter the compute a product depends on?
Worked example

Tracing a Restriction Through a Product Plan

A product team hosts its own model on GPUs bought from one vendor. A new law bans that vendor from selling GPUs to the team's country. What does the team need to check?

  1. 1
    Identify the dependency

    The product depends on GPU supply from a single vendor, so that vendor's sales status is part of the product's risk.

  2. 2
    Apply the regulatory change

    A new law restricts who can buy and sell compute, so the vendor can no longer sell into the country.

  3. 3
    Follow the effect

    The supply the product relies on can disappear without warning, which affects the product directly, not just the budget.

  4. 4
    Reopen the decision

    The team's original build decision assumed that supply would stay available, so it must be weighed again at the next review.

Result

The team must reassess the build option now that its compute supply is no longer guaranteed, even though the original comparison was sound.

Intellectual Property Exposure

The most serious category is intellectual property. Suppose your product is built on a model that was trained using other people's data. The question the source asks is whether you can be certain your product's IP will always belong to you. The answer is not settled, because regulations around intellectual property and AI usage are still evolving. The diagram below traces how the exposure travels from the training data into the product.

Third-party dataOther people's dataModel trained on dataModel inherits the dataProduct built onmodelYour productUnsettled IP questionOwnership is not guaranteedused for trainingserves as baseexposes
How does third-party training data flow into a model and then into a product, carrying IP exposure with it?

The source reports that many IP-heavy companies, such as game studios, hesitate to use AI for fear of losing their IP later on. Their caution reflects a specific risk: the legal ground can shift after they have already built on it. The problem is not only what the law says today, but that a product built now can be affected by a later ruling about the same model.

Build and Buy Compared Over Time

The table below summarizes how the three pressures affect the two options. It is a reading of the source's claims, not a complete accounting of every cost, so it should be used as a checklist for each review rather than as a final verdict.

PressureBuilding in-housePaying a model provider
Price changesOriginal cost estimate can go staleProvider price cuts or rises can change the comparison
Switching effortRequires versioning and evaluation infrastructureAPI convergence eases switching, but each model still differs
RegulationCompute, talent, and data rules add compliance costCompliance and compute rules still reach the provider's supply
Compute availabilityDepends on the vendor able to sell to your countryDepends on the provider's own access to compute
IP questionUnresolved if the model was trained on others' dataUnresolved if the model was trained on others' data

How each outside pressure bears on the build and buy options

Mistakes Teams Make With These Decisions

  • Common mistake

    Treating the build-or-buy decision as final once it is made

    What it looks like

    The team commits to building in-house and never revisits the cost comparison.

    Why it fails

    The source says the best option today may become the worst option tomorrow, so each investment needs repeated review.

    Do this instead

    Schedule a review at which prices, providers, regulation, and IP questions are checked again.

  • Common mistake

    Assuming that switching models is free because APIs look alike

    What it looks like

    A team swaps to a new provider's model without a way to compare the results.

    Why it fails

    Each model has its own quirks, strengths, and weaknesses, and without versioning and evaluation infrastructure the team cannot tell whether the swap worked.

    Do this instead

    Build the ability to compare model versions and measure results before switching.

  • Common mistake

    Budgeting without room for regulatory cost

    What it looks like

    A plan leaves out the compliance work that a new regulation requires.

    Why it fails

    Regulation can add a large, unplanned expense to work that was budgeted without it, as the GDPR example shows.

    Do this instead

    Treat regulatory compliance as a cost that can appear after the plan is set, and review it at each cycle.

  • Common mistake

    Assuming compute supply is guaranteed

    What it looks like

    A product plan counts on one vendor's GPUs without considering a sales ban.

    Why it fails

    New laws can restrict who can buy and sell compute, so supply can disappear overnight.

  • Common mistake

    Assuming the IP question is already answered in the team's favor

    Why it fails

    The source treats the question as unsettled, and the legal ground can shift after a product is built.

    Do this instead

    Record the IP exposure as an open item and reassess it at each review.

Practicing a Review

MEDIUM

A team chose to build its own model two years ago because it was cheaper than paying a provider. Today, provider prices have fallen, a new regulation has added compliance work, and the team is unsure whether its training data was licensed. Using the four review checks, list what the team should examine, and say whether its current choice should be kept, built, or bought, giving one reason for your answer.

Hints
  • Go through prices, providers, regulation, and IP exposure in that order.
  • Notice which pressure is a routine engineering matter and which could threaten the product itself.
  • A decision can be kept for now and still be flagged for a faster review.

Key Takeaways

  • A sound build-or-buy decision reflects the prices and providers of its moment, and it can become the wrong choice when those change, so each investment needs repeated review.
  • Market pressures are often manageable with versioning and evaluation infrastructure, but regulation can add unplanned costs and can restrict compute availability overnight.
  • Building on a model trained with other people's data raises an intellectual property question that should be treated as unresolved and reassessed as the legal ground shifts.

Related concepts

More concepts starting with C