The short answer
There are three options, not two. Buy a product when the use case is common to every business like yours and your requirements are ordinary. Configure the platform you already own when the capability is inside it and your data is already there. Build when the use case is specific to how your business works, needs your knowledge and your rules, or has to connect systems no product connects. Run the five tests below for each use case, and expect a mix.
The three options, honestly described
Buy a product. Fastest to start, cheapest per month at small scale, and shaped by somebody else’s idea of your process. You get their roadmap, their data handling and their limits. Fine for commodity work; painful when your process is the reason customers choose you.
Configure what you own. Most businesses on a major platform already licence assistants, automation tools and, increasingly, agent builders. Setting them up properly is the cheapest AI project available, and it is under-used because nobody in the business has time to learn what the platform can do. It stops where the platform stops: connecting to systems outside it, following rules it cannot express, answering from knowledge with citations.
Build. Designed around a model, using your knowledge, your systems and your rules. Most expensive up front, most flexible, entirely yours, and the only option when the use case is particular to you. It also carries the obligation to run it: monitoring, changes, and the model usage bill.
Five tests, per use case
- Is it particular to you? If the process is how your business competes, buying somebody else’s version of it gives away the difference. If it is the same in every business (expense claims, meeting notes), buy or configure.
- Does it need your knowledge with a source? Products answer from their own material or generic training. If the answer must come from your documents and cite them, that is at least a configured knowledge base and often a build.
- Does it need your rules to hold? Approval limits, escalation, what may never be done alone. Products let you set some rules; a build lets you set all of them and test that they hold.
- What does it have to connect to? A product connects to what its vendor chose. If your use case reads from the ERP and writes to the CRM and both are unusual, a build with a small integration layer is often cheaper than forcing a product to fit.
- What is the volume? Per-seat and per-use product pricing is cheap at low volume and expensive at high. A built system costs more to make and less to run at scale. Do the three-year sum, not the first-year one.
The trap on each side
The buy trap is a stack of products that each do one thing, with your knowledge copied into each, permissions checked in none, and no single record of what the AI in your business did today. Cheap individually, expensive together, and impossible to govern.
The build trap is engineering for its own sake: building something the platform already did, or building a first project so ambitious it never ships. The guard against both is the same: an architecture that says what is shared (the knowledge base, the policy, the record, the identity) and what each use case is allowed to be different about.
Do the sum over three years
For each option, add the setup cost, the monthly cost at this year’s volume and at the volume you expect in year three, your own staff time, and the cost of leaving (exporting your data and knowledge, retraining people). Products look cheapest in year one and are often not by year three; builds look expensive in year one and are often cheapest by year three at high volume. Configuring what you own is usually cheapest across all three years for the work it can do, which is why it should be checked first every time.
What the honest answer usually looks like
A business of any size ends up with the assistant configured on its platform for everyone; one or two products for commodity work; and one or two built systems for the processes that are genuinely its own, sharing one knowledge base and one policy. The strategy work is deciding which use case goes in which column and in what order, with a business case for the first build so the board can see why it is not a product.
A worked example: three use cases in one business
Take a forty-person distributor, described as an example. Staff expense claims are the same in every business; a product does it well and cheaply, so buy. Supplier invoices arrive by email and need to become draft bills in the accounting system; the platform the business already runs has the automation and document tools to do most of it, so configure, with a small integration where the platform stops. Customer quoting follows rules that are the reason customers stay: pricing tiers, stock commitments, a manager’s approval above a threshold; no product knows those rules, and the agent has to read stock and write to the CRM, so build, on the same knowledge base the assistant uses.
Three use cases, three answers, one architecture. The strategy engagement is where those three decisions are made and ordered, and the order matters: configure first, because it is cheapest and it teaches the business how AI behaves on its data; buy second; build third, when the knowledge base and the policy exist for it to sit on.
Where to go from here
The AI Strategy service on this site produces exactly that: an opportunity map of your use cases, a build-buy-configure decision for each, a ranked roadmap and a business case for the first item. If you already know the use case and want the design, AI Architecture is the next page. The AI Opportunity Score below tells you in five minutes whether you are choosing between products or ready for something built.
Published 12 September 2026 · Be AI