Build vs Buy for AI: When an Off-the-Shelf Tool Is Enough and When You Need a Custom Agent

Two years ago, "should we use AI?" meant "should we build something?" There was little to buy, so every serious AI project was a custom one. That's no longer true. Nearly every SaaS product a business already pays for has shipped an AI feature: support agents inside helpdesks, deal summaries inside CRMs, product descriptions inside ecommerce platforms, invoice matching inside accounting tools. Many are good enough to switch on today. That changes the first question every AI conversation should start with. It's not "what should we build?" anymore — it's "what do our existing tools already do, and where exactly do they stop?" We have this conversation with nearly every client, and the honest answer is often "buy" or "switch on what you already have." This post is the framework we use: when off-the-shelf is enough, when a custom agent earns its cost, what the middle ground looks like, and how to decide without either overspending on a build or settling for a tool that can't do the job.

The core argument in one paragraph: buy when the workflow is standard, lives mostly inside one tool, and isn't what makes you different — the vendor has already solved it for thousands of customers, and you'd be paying to rebuild their product. Build when the workflow crosses several systems, depends on rules that are specific to your business, needs control over data or cost that a vendor won't give you, or is part of how you win customers. Most businesses land in between: buy the platform, then build a thin custom layer where the platform stops. The expensive mistakes come from deciding on the wrong basis — building because custom feels more serious, or buying because the demo looked good — instead of testing the actual workflow against the actual tool.

Why the question changed: every SaaS tool now ships AI

The economics flipped quickly. When a helpdesk vendor builds an AI agent, it spreads the cost across its whole customer base, ships it inside a product you already use, and maintains it as models improve. Your team gets a working feature for a monthly fee, with no integration work for data that already lives in that tool. For common, well-understood tasks, it's very hard for a custom build to beat that on cost or speed.

But built-in AI has a shape, and the shape is set by the vendor's priorities, not yours. It's designed for the median customer of that product. It sees the data inside that product well and the data outside it poorly or not at all. Its rules, tone, and guardrails are configurable within limits the vendor chose. And it improves on the vendor's roadmap, which may or may not include the thing you need next quarter. None of that is a flaw. It's the trade-off you accept in exchange for speed and low cost, and the decision is really about whether that trade-off fits the job in front of you.

When an off-the-shelf tool is enough

Buy, or simply switch on what you already pay for, when most of these are true:

The workflow is standard. Answering FAQs from a help centre, summarising tickets, drafting email replies, writing first-draft product descriptions, transcribing and summarising meetings. Thousands of companies do these the same way, and vendors have tuned their features on all of them. Your version is unlikely to be different enough to justify rebuilding it.

The data lives inside one tool. If everything the AI needs is already in your helpdesk, or already in your CRM, the built-in feature reads it natively with no integration work. Built-in AI is strongest exactly where the vendor owns the data.

Good enough is genuinely good enough. For internal tasks with a human reviewing the output — a summary someone reads before acting, a draft someone edits before sending — an 85% solution that ships this week often beats a 95% solution that ships in three months.

The volume and stakes are moderate. At low to medium volume, per-seat or per-resolution pricing stays affordable, and if the AI gets something wrong, a person catches it before it costs much.

It isn't how you compete. If your customers don't choose you because of how this workflow runs, there's no strategic reason to own it. Use the vendor's version and spend your budget where it differentiates you.

When you need a custom agent

Build when one or more of these is true, because each is something an off-the-shelf feature structurally struggles to do:

The workflow crosses several systems. A customer asks about a delayed order, and the right answer needs the ecommerce platform for the order, the courier's API for tracking, the ERP for stock on a replacement, and the helpdesk for the customer's history. Built-in AI sees its own tool well and the rest poorly. A custom agent, connected through MCP or APIs to every system it needs, can follow the whole workflow end to end.

Your rules are the product. Pricing logic for wholesale customers, refund decisions that depend on order history and customer tier, compliance checks specific to your industry, a sales process with your own qualification steps. When the value is in applying your rules exactly, a generic feature configured through a settings page usually can't encode them, and the gaps show up as wrong answers to your best customers.

You need control over data, cost, or model. Some businesses can't send certain data to a third-party tool's AI, need to keep it in a specific region, or need full audit trails of every decision. Others reach a volume where per-resolution pricing costs far more than running their own agent with the cost levers from our cost post. A custom build lets you choose the model, route by difficulty, and own the logs.

It's part of how you win. If the experience itself is what customers choose you for — a product advisor that knows your catalogue deeply, a quoting assistant that turns a two-day process into two minutes — renting the same feature your competitors can switch on gives you nothing they don't have.

The built-in version has hit its ceiling. You've already tried the vendor's AI, measured it honestly, and found specific, repeatable gaps that configuration can't fix. This is the strongest signal of all, because it's based on evidence rather than assumption.

The hybrid middle: buy the platform, build the layer

For most businesses, the right answer isn't pure build or pure buy. It's keeping the platforms you already run on and building a thin custom layer exactly where they stop.

In practice that looks like this. The helpdesk's own AI handles routine questions inside the helpdesk, and a small custom agent takes over the order-related ones that need data from three other systems. The CRM's built-in assistant writes call summaries, and a custom workflow in n8n or Make scores leads against your own qualification rules and pushes the result back into the CRM. The ecommerce platform hosts the store and checkout, and a custom product advisor sits on top of it, reading the catalogue through the platform's API or MCP server.

The hybrid model works because it puts each kind of spend where it pays off. The vendor maintains the commodity parts — hosting, UI, standard AI features, security patches — and your budget goes only to the logic that's specific to your business. It also lowers risk. If the custom layer underperforms, you still have the platform's default behaviour underneath it; if the vendor's AI improves next year, you can shrink the custom layer instead of rebuilding everything.

The hidden costs on both sides

Both paths have costs that don't appear in the first quote, and a fair comparison counts them all.

What buying really costs. Per-seat and per-resolution pricing looks small at pilot volume and can grow quickly as usage rises, sometimes past what a custom agent would cost to run. AI features are often locked to higher plan tiers, so "switching it on" can mean upgrading everyone. Configuration has limits, and the workarounds — manual steps, extra tools, people correcting the AI — become a quiet ongoing cost. Your workflows also become tied to that vendor's product decisions, so a pricing change or a removed feature lands directly on your operations.

What building really costs. The build itself is the visible part. Behind it sit running costs for model usage, hosting, and monitoring; ongoing maintenance as models, APIs, and your own processes change; evals and QA to keep quality from drifting, as in our evals and staging posts; and someone who owns the system after launch. A custom agent with no owner and no maintenance budget degrades quietly, just like an unmaintained website.

The honest comparison is total cost over two to three years at realistic volume, including the people time on both sides — not the first-year subscription against the build quote.

Five questions that decide build vs buy

Run every candidate workflow through these five questions. The answers usually make the decision obvious.

1. How many systems does the workflow touch? One system points to buy. Three or more, with data that has to be combined to give a correct answer, points to build or hybrid.

2. How specific are the rules? If you can explain the logic in a sentence any company in your industry would agree with, buy. If it takes a page of exceptions that only your team understands, those rules need to live in code you control.

3. What happens when it's wrong? Low stakes with a human reviewing points to buy. High stakes with customers or money involved points to a build with your own guardrails, approval steps, and evals.

4. What will it cost at real volume in year two? Price the vendor at your expected volume, not the pilot. Price the build including running costs and maintenance. Compare the totals, not the first invoices.

5. Does it set you apart? If customers would notice and care that yours works better than a competitor's, own it. If they wouldn't, rent it.

Two or more answers on the build side is a strong signal to build or go hybrid. Mostly buy-side answers means switch on the vendor's feature, measure it honestly for a month, and revisit only if it hits a clear ceiling.

The pragmatic version for a small business

If you're an SMB deciding where to start, begin with what you already pay for. List the AI features included in your current helpdesk, CRM, ecommerce platform, and productivity tools, and switch on the ones that match a real pain point. Measure them for a month against something concrete: resolution rate, time saved, errors caught. Where they work, stop there; you've just saved the cost of a build. Where they fall short, write down exactly how — which questions they get wrong, which systems they can't see, which rules they can't follow. That list is the scope of your custom layer, and it's far smaller and cheaper than building everything from scratch.

When an agency or vendor pitches you a custom build, ask one question: what would the off-the-shelf version of this get wrong, specifically? A good partner can answer with concrete gaps. If the answer is vague, you may be paying to rebuild something you could switch on tomorrow.

The strategic point underneath: as AI becomes a standard feature of every business tool, the commodity parts of AI are getting cheaper and better on their own. That's good news, because it means you no longer have to build everything to get value from AI. It also means the only AI worth building is the AI that's genuinely yours — the workflows that cross your systems, apply your rules, use your data, and shape the experience your customers choose you for. Buying the commodity and building the differentiator isn't a compromise. It's the most efficient way to spend an AI budget, and it keeps you free to adopt whatever the next round of vendor features and models brings.

Every AI engagement we start begins with this build-vs-buy review — what your current tools already do, where they stop, and what a custom layer would need to cover — because the best AI project is sometimes the one you didn't need to build.