Once a business has decided which bottleneck it is attacking, the next question arrives immediately: do we build this ourselves or buy something off the shelf?
It is a reasonable question and it is framed wrong. Build versus buy is a binary borrowed from an era when software came in boxes and the two options really were the only two. Applied to AI systems it produces predictable failures in both directions. Companies build things that three vendors already do better. Companies buy things that cannot possibly know their business rules, then employ two people full time to work around the gap.
There is a third option, and in our engagements it accounts for the majority of what actually gets delivered.
Buy when the capability is generic and someone else has the data
Some capabilities are genuinely commodity, and the vendors who sell them have an advantage you cannot replicate: they have seen far more examples than you ever will.
Speech recognition is the clearest case. Document extraction is another. Translation, general-purpose language models, vector storage, email deliverability. In each of these the quality of the result is a function of scale, and the scale belongs to somebody else. Building your own is not ambitious, it is expensive nostalgia.
The test is simple. Ask whether your version of this capability would be better than the vendor's because of something specific to your business. If the honest answer is no, buy it, and spend the attention you just saved somewhere it compounds.
Build when the rule is yours and the rule is how you win
The opposite case is narrower than most people assume, but it is real and it matters.
Build when the logic encodes something proprietary: how your firm qualifies a lead, what your reviewers actually check, the sequence of conditions that separates a deal worth chasing from one that will waste a quarter. That logic is usually undocumented, lives in two or three senior heads, and is the reason the business performs the way it does.
No vendor can sell it to you, because no vendor knows it. Attempts to buy it produce a generic scoring model that your team correctly ignores.
Our work on call auditing is an example. The transcription underneath is bought, and we would not consider building it. What sits on top, the model that scores a conversation against the specific things a particular business cares about, is built, because the criteria are the client's and they are not generic. That system holds at 93% agreement with the firm's own reviewers on the same calls. The figure is meaningful precisely because it is measured against those reviewers and not against a general standard.
Orchestrate: the part nobody scopes
Here is what we find in most mid-market businesses. They are already paying for six to ten capable systems. A CRM. A telephony provider. A document store. An accounting package. A messaging platform. Often a reporting tool nobody opens.
Each one is competent. None of them talk to each other in a way that reflects how the business actually runs. The connective tissue is people: someone reads the output of system A, decides something, and types it into system B. That person is, functionally, the integration layer, and they are the slowest and most expensive component in the chain.
Orchestration is replacing that layer. Not with a new system that sits alongside the others, but with agents and workflows that move between the tools the business already owns, apply the business's rules at the decision points, and escalate to a human where the business has decided a human is required.
This is unglamorous and it is where most of the value sits. It requires no new licences. It usually requires no migration. It changes nothing about what the team sees on screen, which is the main reason it gets adopted rather than resisted.
When a client tells us they need an AI system, orchestration is what they need somewhere between six and seven times out of ten.
The integration surface is the real cost
Whichever way the decision goes, the cost that gets underestimated is not the model and it is not the interface. It is the integration surface: authentication, rate limits, field mappings, the four fields that are free text in one system and enumerated in another, the records that exist twice with different spellings.
A useful discipline during Design is to count the integration points before estimating anything else. A system touching two tools is a different order of work from one touching five, regardless of how similar the two sound in a requirements document. We have seen a "simple" automation cross eight systems once the real path was traced, and a genuinely ambitious agent touch only two.
The Discover map from the first stage is what makes this countable rather than guessed.
A question that settles most arguments
When a team is deadlocked between building and buying, one question tends to break it:
If the vendor changed their model tomorrow, would this capability still be ours?
If the answer is yes, because what you own is the rules, the data and the workflow, then buying the underlying capability is safe. You have made yourself dependent on a component, not on a company.
If the answer is no, because the vendor holds the logic that makes the thing work for you specifically, you have outsourced the part that was supposed to be your advantage. That is the situation to avoid, and it is worth paying to build your way out of.
Where we land
Most engagements resolve into the same shape. Commodity capability bought. Business logic built, and kept in the client's repository under the client's control. Everything connected by orchestration across tools the client already pays for.
That shape is not a compromise between the two traditional options. It is what a system looks like when each layer is sourced according to where the advantage actually lives. It is also, not coincidentally, the cheapest of the three to run and the easiest to change when the business changes.
The decision belongs in Design, before anything is built and while it is still free to change your mind. That is the stage where it costs a conversation. Afterwards it costs a rebuild.