Every few months a leader faces the same question about some new AI capability: do we buy a tool that already exists, build our own, or hold off for now. The pressure to do something is real, and it pushes people toward the two active answers. But the choice deserves a calmer look. Most of the time the right call is obvious once you ask the right questions, and one of those answers is to wait.
Buy when the problem is common
Buy when the thing you need is common, well understood, and not the reason customers choose you. Plenty of good products already handle document summarization, meeting notes, support triage, transcription, and basic drafting. These are solved problems with mature tools behind them. Building your own version is expensive, slow, and rarely better than what you can license this quarter.
The test is whether the capability is a differentiator or a cost of doing business. If a competitor could buy the same tool tomorrow and it would not change your position, buy it too. Spend your scarce engineering attention on the things only you can do.
The trap here is pride. Teams talk themselves into building because their situation feels special. Usually it isn’t. If the workflow is standard and the data isn’t unusual, a bought tool that people actually use beats a home-grown one that takes a year and arrives tired.
Build when it touches your core
Build when the capability sits close to your advantage, when your data or workflow is genuinely specific, or when control and privacy matter enough to justify the cost. If the way you do a thing is part of why you win, an off-the-shelf tool that does it the average way will flatten what makes you distinct. That is the case for building.
The same holds when your data is peculiar to you and hard to hand to a third party, or when regulation, confidentiality, or customer trust means you need to keep it in your own hands. Build is the more expensive road, and it commits you to owning the result for years. Be honest that you are taking on maintenance, not just a launch.
One caution: building rarely means building from nothing. Most of the time you are assembling existing pieces around your data and your process. The valuable part is the fit to your business, not the plumbing. If the whole thing could be replaced by a subscription, it probably should be.
Wait when the picture isn’t clear
Wait when the value isn’t clear, when the tooling is changing quickly, or when you honestly could not adopt the thing today. Waiting has a bad reputation, as if it were the same as doing nothing. It isn’t. Waiting is a decision to spend your money and attention later, when you know more and the ground is steadier.
The tooling in this area moves fast. A capability that costs a fortune to build now may arrive as a cheap, reliable product within a year. Committing early can lock you into a worse version of something you could have bought better and later. And if your team cannot absorb a new tool right now, buying or building it only produces expensive shelfware. A modest capability people rely on beats an ambitious one nobody uses.
Wait is a legitimate answer, and often the wise one. It is also not permanent. You revisit it when the value clears up or the tools settle.
The questions that decide it
Four questions carry most of the weight. Is this our differentiator? How specific is our data and workflow? What is the cost of being wrong? Can we actually adopt it now?
If it is your differentiator and your data is specific, lean build. If it is common and the products are mature, buy. If the value is fuzzy, the tools are still moving, or you are not ready, wait, and set a date to look again. None of these is a life sentence; you can buy now and build later, or wait now and move fast once the picture is clear.
Getting this right is less about the technology than about being honest on those four questions. A short, fixed-scope Business Diagnostic is built to answer exactly that: where to buy, where to build, and where the right move is to wait.