- Buy for tasks most businesses share: transcription, first-draft emails, basic support replies. A mature tool beats anything you would build yourself.
- Build when the value comes from your own data, your pricing rules or a workflow that spans systems no generic tool connects.
- The test: if a competitor bought the same tool, would they get the same result? Yes means buy. No means the advantage is yours to build.
Every business we talk to eventually asks the same question: should we buy an AI tool off the shelf, or build something of our own? There is no universal answer, but there is a clear way to think about it. The short version: buy first, and build once a process is proprietary, valuable or repeated often enough that a generic tool starts costing more than it saves.
The case for buying
Off-the-shelf AI tools now exist for almost everything: support chatbots, sales email drafting, meeting transcription, invoice reading, content generation. They are built and maintained by vendors whose whole job is that one problem, and there are good reasons to start there.
- Speed. You can be using most tools the same day. No development cycle, no requirements meetings, no waiting for a build.
- Lower upfront cost. A monthly subscription rather than a project budget. For a business that is not yet sure how much value AI will deliver, that is a much smaller bet.
- Someone else maintains it. The vendor updates the model, patches security and improves the product. You do not need engineers to keep it running.
- Proven for common tasks. For generic, well-understood jobs (scheduling, transcription, tagging support tickets) a mature tool with thousands of customers is probably better than anything you would build.
The catch is that off-the-shelf means built for the average customer, not for you. The tool does not know your product catalogue, your pricing rules, your compliance requirements or the way your team actually works. You adapt your process to fit the tool. That is a fine trade for many tasks. It is a bad trade for the parts of your business that make you different from your competitors.
The case for building
Custom AI development means building something, an application, a workflow or a set of agents, around your data, your process and your rules. It costs more and takes longer up front, and it solves problems generic tools cannot touch.
- It fits your process, not a generic one. A particular approval chain, a non-standard data structure, an industry-specific compliance step: a custom build is designed around that reality instead of bending your process to someone else’s software.
- It can use your own data. Years of sales records, service tickets, engineering documents. That is usually where the real value is, because your data is the thing competitors do not have.
- No per-seat fees at scale. Subscriptions charge per user or per usage tier and compound fast across hundreds of staff or millions of transactions. A custom system costs real money to build and maintain, but it does not scale that way.
- You own it. No dependence on a vendor’s roadmap, price changes, or the risk that they get acquired or retire the feature you rely on. That matters more the more central the tool becomes.
The catch here is real too. Custom work takes longer, costs more up front and needs ongoing support. It is the wrong starting point for a task you have not tested yet, and a poor use of budget if a cheap tool already does the job well.
Where the line usually falls
Strip away the hype and the decision comes down to one question: is this task generic, or is it tied to something specific about how your business works?
Generic task: buy
If most businesses in most industries need to do it (draft emails, summarise meetings, transcribe calls, first-draft marketing copy, basic customer replies) buy the tool. Someone has already built, tested and refined a good version. You gain nothing by rebuilding it and lose time and money trying.
Your process or your data: build
If the task depends on something unique to you (your pricing logic, your stock system, your compliance rules, years of internal documents, a workflow that spans several systems that do not talk to each other) that is when building starts to make sense. A generic tool cannot reach into your data or copy a process that is specific to you, however good it is in general.
The mix most businesses end up with
Very few businesses are purely buy or purely build. Most end up with off-the-shelf tools for the generic, high-volume tasks and custom work for the handful of processes that are core to how they compete.
A common pattern: a company uses one bought tool for transcription and another for email drafting, and has a custom-built agent that pulls from its CRM, its stock system and its internal pricing rules to produce quotes, because that process is specific to it and touches systems no generic tool was built to connect. The transcription tool is bought because it is a solved problem. The quoting agent is built because it depends on proprietary data and a workflow unique to that business.
Building also rarely means starting from scratch. More often it means building the connective layer, the integrations and logic that tie several tools (some bought, some custom) into one working system. That is more realistic, and cheaper, than one monolithic custom build.
Five questions before you decide
- Has this exact problem already been solved by a mature tool? Several established vendors competing in the space is a sign the generic version is good enough for most cases. Buy first and see.
- Does the task depend on your internal data or a process unique to you? If so, a generic tool will hit a ceiling fast, and that ceiling is where building starts to pay.
- How much volume, or how many seats? High volume changes the sums on subscription cost versus a one-off build.
- What happens if the vendor changes pricing, drops a feature or is acquired? Acceptable for a low-stakes task. Not acceptable for a tool your operation depends on.
- Can you support something custom after launch? A build is not a one-time project. It needs upkeep, like any other software.
None of this needs to be guesswork. Most businesses do not have a clean answer sitting in front of them; it takes a short, structured look at where the value and the risk actually sit. That is what an AI strategy engagement is for: mapping your processes against what exists off the shelf and being honest about where a build is worth it and where it is not. Getting it right the first time avoids the two expensive mistakes: building something a cheap tool would have handled, or forcing a generic tool to do something only a purpose-built system can.
Questions
Is it cheaper to buy?
Can we start with a bought tool and build later?
Does building mean we need our own developers?
Leads every 90-day programme personally. Writes these notes from the projects that shipped and the ones that did not, so you can skip the second kind.
