Should We Buy an AI Tool or Have One Built?

Should we buy an AI tool or have something built?

Buy the tool first and build the gap. The question is almost never whether a product exists, because it does. It is whether the product covers the work end to end or leaves you with a person moving data between it and everything else.

Three questions decide it in about ten minutes. Does a product already do this for businesses like ours, and does it do the whole job rather than the interesting part? Would the way we do this be recognisable to a competitor, or is it genuinely ours? And when the product is in place, does somebody still sit between it and the next system?

Answering those honestly usually produces a shape rather than a side. Most businesses end up buying three or four products and building the connective work between them, which is also the part that creates the capacity, because the time was never going inside the product. It was going into carrying things between products.

The reason firms get this wrong in both directions is that the two options are sold by different people. Software vendors demonstrate the part their product covers and do not dwell on the part that stays manual. Development firms quote for everything, because everything is billable. Neither party has an interest in the sentence "buy that, and let us connect it to the two systems you already run."

The decision also has a sequence to it. Buy the product, run it for a quarter, watch where the manual work collects, and build against what you observed rather than what you predicted. Builds specified before the product is live are specified against a guess, and guesses are the expensive part.

What does "build" actually mean in 2026?

Building in 2026 does not mean building a model, and it does not mean writing software from nothing. It means assembling: using existing models through their interfaces, connecting the systems you already run, and encoding your rules and your sequence into something that executes reliably.

That distinction matters for cost and for risk. Nobody sensible trains a model for an ordinary business problem. The expensive parts of a build are elsewhere: getting data out of systems that were not designed to share it, handling the cases your process has but your description of it did not mention, and making the thing reliable enough that nobody checks it twice.

A useful way to see the difference is what each side owns when something breaks. Buy, and the vendor owns the product while you own whatever you wrapped around it. Build, and somebody owns all of it, which has to be a named arrangement rather than an assumption.

Scale changes the maths, and the direction may surprise you. McKinsey's State of AI survey, fielded in May and June 2026 across 1,719 respondents in 97 countries, found 32% of organisations declining to buy at least one software product or feature because coding agents meant it could be built in-house instead. The shift is concentrated where the capability already sits: nearly half of the survey's high performers had made that choice, against 31% of everybody else. Building is getting cheaper for the organisations that already had engineers. It is not getting cheaper for a 40 person business, which still has to get the capability from somewhere.

For the question of who does the building, in-house, freelancer or firm, see automation consultant versus in-house, which covers that axis properly.

Build versus buy: how do the two compare, line by line?

Build versus buy compares like this: buying wins on speed, support and price certainty, and building wins on fit, ownership of the sequence, and not paying per seat forever for software that half-fits.

	Buy a product	Have it built
Time to working	Days to weeks	Weeks to months, depending on the systems involved
Fit to how you work	You adapt to the product	The system follows your process
Cost shape	Predictable subscription, usually per user or per unit	Investment up front, then running and maintenance cost
Who fixes it	The vendor, on their timetable and their roadmap	Whoever you arranged it with, named in writing
Your data	In their system, exportable to the extent they allow	In systems you control
Risk if it fails	You cancel, having lost time	You own an asset that needs finishing or retiring
Gets better by itself	Yes, with their roadmap, which may not include your request	Only when somebody improves it
Best for	Work thousands of businesses do identically	The joins, the exceptions and the sequence that is yours

Two rows do most of the deciding. Fit to how you work is where buying hurts, because the gap between a product's assumptions and your process gets filled by a person, every day, invisibly. Who fixes it is where building hurts, because an unowned custom system decays, and the decay is slow enough that nobody notices for a year. What that maintenance actually involves is in who maintains an AI automation.

When is buying obviously the right answer?

Buying is obviously right in four cases, and recognising them saves most of the money in this category.

When the work is identical across businesses. Payroll, accounting, scheduling, email, storage, e-signature, call recording. The product is better than anything anybody would build for you, because its vendor has spent a decade on the edge cases you have not met yet.

When the regulated version is the hard part. Payment processing, patient records, payroll tax. Buying includes somebody else's compliance work and their liability, which is worth more than the fit you give up. The practice-specific version of that line is on the dental and medical practices board.

When you have not run the process long enough to know what it is. A build encodes a process, and if the process changes next quarter the build is wrong next quarter. Buy something flexible, run it, and revisit.

When the volume is low. Ten of something a month does not justify a system, however annoying each one is. Volume, not irritation, is what makes automation pay, and the arithmetic is in how much of my business can be automated.

There is a fifth case worth naming because it embarrasses people into building: when a product is nearly right and the gap is a report. Ask for the export, write the report once, move on. Plenty of custom projects exist because nobody wanted to admit the real requirement was a spreadsheet.

When does building actually pay?

Building pays when the work sits between systems, when your rules are your advantage, or when the per-seat price of a product has outgrown what it does for you.

The strongest case is the join. Quote accepted in one system, job created in a second, parts ordered from a third, customer updated by text, invoice raised on completion. No vendor sells that sequence because the sequence is yours, and in most businesses the sequence is where the week goes. This is also the work that produces capacity rather than convenience, because it removes handoffs rather than speeding up typing.

The second case is a rule set nobody else has. How you price an unusual job, how you decide which lead gets called first, how you schedule around your constraints. Encoding that is building a piece of your own business, and it travels with you.

The third is economic rather than functional. Software priced per user punishes you for growing, and at some headcount the subscription for a tool you use for one narrow purpose exceeds what the capability is worth. That crossover point is real, it arrives quietly, and nobody at the vendor is going to point it out.

A fourth case, less common but decisive when it applies: when the product cannot be made to stop doing something. Compliance constraints, data residency, a customer contract that forbids a subprocessor. If a product cannot satisfy a hard constraint, fit does not matter.

What BLACKSIG does in these cases is decide the shape before anybody writes anything. The strategy work maps how the business actually runs, names which parts should be bought, and specifies only the joins worth building. Our engineering team builds those, they run on our infrastructure, and we operate them from there.

What does the evidence say about which one succeeds?

The evidence says buying succeeds more often, and the gap is large enough that anybody proposing a build should have to argue for it.

MIT's NANDA initiative published The GenAI Divide: State of AI in Business 2025, built from interviews with business leaders, an employee survey and an analysis of public AI deployments. Its finding on this question is that deployments built with an external partner reached full production about twice as often as the ones built internally. In press interviews around the report, its lead author put purchased tools from specialist vendors at roughly two thirds success, against about a third as often for internal builds. The report is careful about what that proves: the gap may reflect what kind of organisation picks each route rather than the route itself.

That is also the study behind the widely quoted finding that only about 5% of pilots produced measurable impact on profit and loss. Read it as a statement about pilots that never reached production rather than about the technology.

Gartner, in a forecast published in June 2025, predicted that over 40% of agentic AI projects would be cancelled by the end of 2027, naming escalating costs, unclear business value and inadequate risk controls. The same analysis described "agent washing", meaning vendors rebranding chatbots and older automation as agents, and estimated that only around 130 of the thousands of vendors claiming agentic products were genuine.

Read together, those findings point at one conclusion rather than two. Both halves of the market oversell: vendors oversell what a product covers, and builders oversell what a bespoke system will do. The decision that survives both is a narrow one with a named owner and a measurable before and after, which is the same thing that separates projects that work from projects that stall. The general pattern is in why AI automation projects fail.

What does each option cost over three years?

Each option costs what it costs over three years rather than at purchase, because the two have different shapes and a one year view flatters buying.

For a bought product, count the subscription at the headcount you expect to have in year three rather than today, implementation and data migration, the integration work needed to connect it to what you already run, training, and the cost of whatever stays manual because the product does not cover it. That last line is the one left out of every comparison, and it is often the largest.

For a build, count the build itself, the running costs of the services it uses, maintenance and monitoring, the cost of changes as the business changes, and the risk cost of the person or firm who knows how it works becoming unavailable. The useful planning assumption is that a system you own is a commitment rather than a purchase, and it should be budgeted that way from the start.

Then compare both against the cost of doing nothing, measured properly: hours at loaded cost, plus the work you are turning away because nobody has capacity for it. Doing nothing is the option that never appears in a vendor comparison, and it is frequently the right answer for a year.

One rule about the arithmetic. Count only the hours that actually leave the building or get re-used for billable work. Time that moves from one task to another is not a saving, and counting it is how businesses end up with a project that proved itself on paper and changed nothing. The method is in how to measure whether AI automation is saving money, and the cost drivers for the build side are in how much AI automation costs.

Frequently asked questions

How much does it cost to have an AI system built instead of buying one?

What moves the number is how many systems have to be connected, whether they have usable interfaces, how many exceptions your process carries, how much accuracy checking stays in the path, and how much of the work has to run unattended. A single connection between two systems with clean data is a different job from a sequence crossing five systems, two of which are older than the business's current owner. BLACKSIG does not publish a rate card; scope is set on the call once the strategy work has established what is worth building and what should be bought. The drivers are in how much AI automation costs.

How do we decide without spending six weeks evaluating?

Pick the one process costing you the most hours. Spend a week finding out whether a product covers it end to end, including the steps before and after. If it does, buy it. If a person would still be moving data in or out of it every day, that movement is the thing to build, and the product is still worth buying. Most of the time the answer is both, in that order.

Is a custom build better than an off-the-shelf tool?

Better at fit, worse at nearly everything else, and the evidence says it succeeds less often. A product carries a decade of other people's edge cases, a support line and a roadmap. A build carries your process and an owner. The combination usually beats either, which is why the useful question is which parts, not which one.

Can our process be automated with an off-the-shelf tool if it is unusual?

Partly, and the honest test is which part is unusual. If the unusual bit is a rule or a sequence, a product plus a thin piece of built logic around it will do. If the unusual bit is that nobody has written the process down and it runs differently depending on who is on shift, neither option works yet, and the first job is the process rather than the software.

What happens to a custom build if the firm that made it disappears?

That is a question to settle in the contract rather than afterwards. The code, the hosting accounts and the API keys should sit in accounts your business owns, the documentation should be good enough for another engineer to pick up, and the arrangement for who keeps it running should be written down. Systems BLACKSIG builds run on our infrastructure and we operate them from there, and what that covers is set out before anything is built, not after.