Choosing an AI consultancy, answered in full.

Buy when being average at the workflow would cost you nothing. Build when the workflow is part of how you compete and you already have engineers who can carry evaluation, monitoring and model upgrades as a standing job rather than a project. Have someone build it with you when the workflow is differentiated and that capability is not there yet. The deciding question is not technical: it is whether your version of this process is worth being better at than everyone else's. A useful second test is where the difficulty sits. If it is in the volume, that is a product problem and products are good at it. If it is in the exceptions, that is a build problem, because your exceptions are specific to you and no vendor roadmap will reach them.

When the process is not differentiated, when you need something running this quarter on a pilot budget, and when you would rather a vendor's engineers carried evaluation, monitoring and the model upgrade treadmill than yours. A vendor who sees a hundred customers' edge cases will often be ahead of anything you would build for a common workflow. Two things stop it. If your exception cases are the reason the process is expensive, you will be configuring around them indefinitely. And if your risk function has to evidence how a decision was reached, ask to see the decision trail the product exposes before you sign rather than after.

When the workflow is a differentiator you intend to keep changing, when the value is in data that is already yours, and when you have engineers who can own evaluation, monitoring and model deprecation as a standing job rather than a project. The costs to price in are that the first months are tuition paid at your own salary cost, that the engineers you would use are usually the ones holding the estate up, and that a great deal of the year goes on building the parts that are the same for everybody, meaning orchestration, retrieval and evaluation harnesses. The failure that is not about engineering at all is the organisation staying the same shape, which is how a working system ends up unused.

Yes, and it is usually the right shape. Models, hosting, search and retrieval, orchestration frameworks and observability are bought by almost everybody building this way, and building your own version of them is where a year disappears. What is worth building is the comparatively thin layer that encodes your exceptions, your policy and your data. If a supplier proposes building the commodity layer for you, ask them why, and ask what you would be able to change in it a year later without them.

A partner builds inside your estate and your repositories, paired with your engineers rather than in a separate stream, and leaves on a date agreed at kickoff. The measure of whether it worked is not the demonstration, it is whether your own people can run and change the thing without the supplier. On a live engagement, the client engineer who paired on a whole two-week proof-of-concept build finished it saying they were 70% confident they could run the process unaided. That is the number worth asking any supplier for, and it is worth being suspicious of anyone who answers 100%.

Cheaper to start, almost always buy. Cheaper over three years, it depends entirely on whether you would have kept changing the thing, and no price list answers that. We publish our own build prices: £20,000 to £55,000 fixed for a proof of concept and £70,000 to £85,000 a month for a build team of three. We will not publish a licence figure for products we do not sell. The number both sides of the argument usually leave out is run cost: inference, the platform, storage and search, evaluation and monitoring, and the human review your process still needs. On a build that lands on your own vendor contracts inside your own tenancy, and Tenhaw takes no margin on any of it. On a licence it is inside the subscription until your volumes move. Put it in the business case at the start rather than finding it in year two.