AI strategy
When to build, when to buy, when to wait
Most conversations about bringing AI into an industry workflow are framed as a binary: should we build this ourselves, or should we buy it? In my experience leading platform programs, that framing is incomplete. There is a third option that serious teams use more often than they admit, and should use more deliberately: wait.
Build, buy, and wait are not moral categories. They are judgments about uniqueness, ownership, timing, and whether the organization can absorb another system. Getting the judgment wrong is expensive in different ways. Building when you should have bought leaves you maintaining a tool that is not actually your advantage. Buying when you should have built can lock a distinctive workflow into someone else’s roadmap. And refusing to wait — launching because the room is ready to launch — is how I have seen teams collect pilots that never become a platform.
Start with the work, not the catalogue
The first mistake is to start with a vendor list, or with an internal wish to “have a platform.” Start with the work. Is the workflow common, or is it distinctive to how you operate? If many organizations do this job in roughly the same way, buying is usually the more honest path. You are unlikely to win by rebuilding a solved commodity, and you will have to keep rebuilding it as the underlying capability moves.
If the workflow is distinctive — if the value is in your process, your data, or the way your teams make exceptions — then you should be cautious about handing the method to a vendor you do not control. That does not automatically mean “build everything.” It means you should own the parts that make the work yours: the logic, the data, the review steps, the places where judgment happens. Once you say out loud what must be owned, the rest of the decision gets quieter.
When buying is the serious choice
Buying is not the timid choice. It is often the more disciplined one. I buy, or I recommend buying, when three things are true. The work is well understood. The market already has tools that can be operated by a normal team, not only by the people who did the pilot. And our advantage is not in owning the method, but in how we use the output.
The test I use is simple: if we stopped maintaining this ourselves in a year, would we have lost something important, or only something convenient? If the answer is convenient, buy, and spend the attention on adoption and review. What you cannot buy is accountability. Even with a vendor, someone inside the organization has to own the outcome, the exceptions, and the decision to keep going or stop.
When building is worth it
Building is worth it when the capability needs to sit close to a process you already run, when the data should not be scattered into a tool you cannot inspect, or when you are trying to create a platform that other teams can use in ways a single product will not support.
I have seen platforms scale when they started from a real workflow, served more than one team without pretending all teams were the same, and had an owner who treated the platform as an operating system, not a demo environment. I have also seen internal builds stall because they were justified by pride — “we should own this” — rather than by a clear statement of what had to be owned, and why.
If you build, build the smallest thing that can become the default path for a real slice of work. A platform that is theoretically general and practically unused is not a platform. It is a prototype with a larger name.
When waiting is the right move
Waiting is the right move when the problem is still fuzzy, when the organization is already mid-change and cannot absorb another one, or when the capability is moving fast enough that a decision made this quarter will look naive the next.
Waiting is not the same as doing nothing. It can mean mapping the work, running a small reversible experiment, watching how a product actually behaves on a real case, or being explicit that you will decide at a named date. What it should not mean is a quiet stall dressed up as a strategy, or a pilot that continues because no one wants to be the person who stopped it.
In my experience, the teams that wait well can say out loud: we are not ready, here is what would make us ready, and here is when we will look again. The teams that wait badly keep a half-alive experiment on the books so they can say they are doing something in AI.
A practical frame
When I have to make this call, I ask four questions. Is the workflow distinctive, or is it common? Do we need to own the method, or only the outcome? Can this organization absorb another system in the next year — including training, review, and the unglamorous work of running it? If we decided six months from now instead of today, what would we lose?
If the work is common, you do not need to own the method, and the organization is already stretched, buy or wait. If the work is distinctive, you need to own the method, and you have an owner who will still be there after the launch, build — narrowly. If the problem is still being argued, or the only urgency is social, wait.
The goal is not to have a position on AI. The goal is to put a capability into a workflow that can stand on its own, or to have the discipline not to.