Build vs buy for your first AI feature: how to decide

Build vs buy is one of the earliest decisions in an AI pilot and one of the least examined. Teams tend to decide by temperament. The engineering-proud build, the risk-averse buy, and almost nobody runs the numbers that would tell them which was right. The regret shows up a year later, deep into a program that is now hard to walk back.

McKinsey’s 2025 work found that roughly 70% of enterprise AI use cases are served well enough by an existing off-the-shelf tool. That single number should make “buy” the default assumption you argue your way out of, not the fallback you reach for after a custom build stalls.

Build when the market genuinely cannot serve you

A hardware founder building an edge-AI home device told me the story behind his decision, and it is a good model for how to make the call honestly. His young son, who is autistic, once ran out of the house toward the pool. The cameras recorded all of it and alerted him to nothing useful, because the off-the-shelf system saw motion, not meaning. That was the moment he started asking why.

He did not jump to building. He went down the “why” and found a real, specific wall: doing always-on vision and reasoning in the cloud was, in his words, prohibitively expensive at the scale he needed, and no existing hardware or software stack did what he wanted on the device. Only after off-the-shelf failed on a concrete requirement, cost and privacy at real-time scale, did building become the rational choice. That is the correct order. You earn the right to build by proving the market cannot serve you, not by preferring to build.

Most teams skip that step. They decide to build because building is more interesting, then discover the cost the platform would have saved them.

There is a second thing worth copying from his approach: he treated cost as a hard requirement, not a footnote. The reason off-the-shelf failed for him was not that it lacked a feature, it was that the economics of doing the work in the cloud did not survive contact with scale. That is a far more useful reason to build than “we could probably do it better ourselves.” A build decision anchored on a specific requirement the market cannot meet is defensible a year later. A build decision anchored on preference is the one that turns into regret.

Put a real cost model on the decision

Before committing to build, write a three-year total-cost model, not a launch estimate.

Development, including the version-two rebuild you always need.
Maintenance, the ongoing cost of keeping an AI feature reliable, which usually outweighs the build.
Infrastructure, inference and serving costs that grow with usage, not with your headcount.
Compliance and headcount, the people and reviews production actually requires.

Most build-vs-buy regret comes from comparing build cost to a license fee and quietly forgetting maintenance, infrastructure, and the engineers pulled off other work. A license looks expensive next to a demo and cheap next to three years of ownership.

How we approach it at Density Labs

The build-vs-buy call is a standard part of the AI Readiness Assessment, our $2,500 engagement. We map your use case against what off-the-shelf tools already do, and we run the three-year cost model on the build side so the comparison is honest. Frequently the most valuable line we deliver is “buy this one, do not build it,” which spares you a custom project that was never going to earn back its maintenance bill.

Buy until the market proves it cannot serve you. Then build with your eyes open, and a cost model already on the table.