“Should we build it or buy it?” is the AI question that shows up earliest and gets answered worst. It usually gets settled by who is in the room: an engineer who wants to build, a vendor who wants you to buy, or a budget line that decides before anyone has weighed the actual trade. None of those is the same as knowing which case you are in.
The honest default in 2026 is buy, configure, and evaluate. Not for lack of ambition, but because the foundation models and the tooling around them improve faster than any one team can build from scratch — a system you wrote eighteen months ago is already competing with the version a vendor ships next quarter. You get further composing what exists and spending your real effort on the parts that are yours: whether the thing works on your tasks, and whether it fits how your team actually operates.
Building is still the right answer sometimes. The point is to know exactly why, before the first commit.
The two columns, honestly
Buy and build are not good and bad. They are different cost and control profiles, and the trade is real in both directions.
| Dimension | Buy & configure | Build custom |
|---|---|---|
| Time to value | Days to weeks | Months, often longer than planned |
| Cost shape | Ongoing and predictable; scales with use | Large upfront, plus open-ended maintenance |
| Differentiation | Same tool your competitors can buy | Yours, if it is built on something they lack |
| Maintenance | Vendor carries upgrades and uptime | Your team owns evals, upgrades, and security forever |
| Control & data | Bounded by the vendor’s terms | Full control of data, model, and behavior |
| Fails you when | Your need is genuinely non-standard | Your need was standard all along |
Read the last row as a pair. Buying fails when you force a standard tool onto a non-standard need and spend the next year fighting its assumptions. Building fails far more often, and more quietly: a team builds custom for a problem the market already solved, and discovers it has taken on a maintenance burden to land in the same place a subscription would have.
The default is buy, and that is a feature
The case for buying is not that custom is hard. It is that the commodity layer keeps getting better for free. When you buy, model upgrades, infrastructure, and most security work arrive without a project. Your attention stays on the questions only you can answer: which tasks matter, what “good enough” means for them, and how the tool lands in a real workflow.
Which is why the work that matters most when you buy is evaluation, not procurement. A bought tool that nobody tested against your own cases is just a bet with a logo on it. Define the tasks, score the tool against them, and you have turned a purchase into evidence. That discipline is the same whether you buy or build, and it is where we point most of a team’s energy early.
When building actually earns it
Building is justified when something specific makes the off-the-shelf option genuinely worse for you, not merely less exciting. In practice it comes down to four conditions, and you need at least one to hold honestly.
Proprietary data. You hold data a general tool cannot see or use well, and the value comes from that data rather than from the model. This is the strongest case for building, because it is the one thing a vendor cannot ship to your competitor next quarter.
A specific workflow. Your process is unusual enough that no product fits it, and bending a product to match would cost more than building the part that is actually yours. Be strict here. “Our workflow is special” is true far less often than teams believe.
A compliance or data boundary. A regulatory, residency, or confidentiality constraint rules out the vendor options, or allows them only in a form that defeats the purpose. For some firms this alone decides it, and a fully owned or on-premise deployment is the only one that clears review.
Economics at scale. Your volume is high enough that paying per use costs more than owning the system would, with the maintenance honestly included. This one flips with scale, so the right answer can change as you grow, and it is worth re-checking rather than assuming.
If none of these holds, a custom build is usually paying, in cash and in your team’s attention, to rebuild something you could have configured.
Building is justified when something specific makes the off-the-shelf option genuinely worse for you, not merely less exciting.
The cost that sinks custom builds is the second year
The trap in build-vs-buy is comparing the wrong numbers. Teams weigh a subscription against the cost of a first version, and the first version is the cheap part. What custom AI actually costs is the maintenance: evaluation sets that catch a regression before a customer does, the work of keeping up as the underlying models change, the security and data handling that never stops, and the engineers whose attention the system now permanently owns.
A vendor amortizes all of that across every customer. When you build, you carry it alone. That is not an argument against building; it is the line item people leave off the comparison, and it is the one that decides whether a build was worth it eighteen months later.
The answer is usually a line, not a wall
The framing as a binary is most of why it gets answered badly. The strongest setups we see are neither pure build nor pure buy. They buy the platform and the model, the parts that are now commodity and improving on their own, and build a thin, owned layer exactly where the differentiation lives: the proprietary data, the retrieval, the evaluation harness, the one workflow that is genuinely theirs.
We made that call building Packwolf. We do not train our own foundation models or run our own inference stack; that layer is bought, it is commodity, and it improves without us. The build effort went where the product actually is: the orchestration that runs a team of agents on a schedule, the memory each agent carries, the approval gates that hold risky actions for a person. Rebuilding the commodity layer would have been a year spent catching up to what a vendor ships for free. The thin layer on top was the only part that was ever ours to own.
That is the move that ages well. You inherit the vendor’s pace and maintenance on the commodity layer, and you own the narrow part that is actually yours, which is the only part worth maintaining yourself. Build less than you want to, own the piece that matters, and buy everything around it.
If you are weighing a specific build-vs-buy call, that is the shape of decision our AI strategy and roadmap work and the AI Decision Memo are built to settle, with the same evaluation discipline that runs through keeping retrieval honest after launch.