Build or Buy? Choosing Between Off-the-Shelf AI and a Custom Build

A business owner asked me last month whether he should pay a developer to build him an AI phone agent. He had been quoted a five figure sum. The system he wanted answers calls, checks a calendar, books a job and texts a confirmation. There is a subscription product that does exactly that for less than the cost of the quote's first invoice.

That is the build vs buy question in miniature, and the honest answer is that off-the-shelf wins more often than agencies like to admit. The interesting part is the minority of cases where it does not, because those cases are specific and you can identify yours in about twenty minutes.

Buying wins by default, and the reason is boring#

An AI product with a few thousand customers has already hit the edge cases you have not thought of yet. Someone has asked it a question in a way that broke it, and the vendor fixed that. Someone has tried to book a job on a public holiday. Someone has spelled their suburb wrong. Every one of those fixes is included in your monthly fee.

When you build, you buy the first version and then you buy every fix afterwards. The quote covers the version that works on the demo call. It does not cover the Tuesday six weeks later when a customer says something the system was never shown, and it does not cover the model update that changes how your prompts behave.

There is also a timing argument. A configured subscription tool can be live in a week or two. A custom build takes months before it touches a real customer. If you are running the 90-day rollout most small teams can actually sustain, a custom build consumes the whole window before you learn anything.

So the sensible default is to buy, run it for a quarter, and let the gaps in the product tell you whether you need something more. Most businesses discover the gaps were imaginary.

The three situations where custom genuinely wins#

Your workflow does not match any product's assumptions#

Products encode assumptions. A booking tool assumes appointments have a start time, a duration and one customer. If your business quotes on site, sends a variable crew, splits a job across three visits and bills partway through, you will spend more energy bending the product than the product saves you.

The test is not whether the tool is imperfect. Every tool is imperfect. The test is whether you would have to run a parallel spreadsheet to make it work. A parallel spreadsheet means the product does not model your business, and you are paying a subscription to do double entry.

Be honest here, because there is a strong temptation to believe your operation is unusual when it is only slightly unusual. Ask whether another business in your trade, in another city, runs it roughly the same way. If yes, someone has probably built a product for it.

Your data cannot leave your systems#

Some businesses hold information that genuinely should not sit on a third party's servers. Legal files under privilege, or client financials where your engagement letter promises a particular handling standard. If that describes you, a self-hosted or private-cloud build stops being an indulgence.

This is worth checking properly rather than assuming. Many vendors offer regional data storage, contractual no-training terms and short retention windows, which resolves the concern without a build. The questions to ask sit in the piece on AI, customer data and privacy, and the New Zealand legal specifics are in the Privacy Act guide. Get answers in writing before you conclude that buying is off the table.

You need to integrate with software that has no API#

This is the most common real reason a build happens. A joinery firm runs a job management system from 2011. A clinic uses practice management software with no public integration. The AI can answer the phone beautifully, but it cannot see whether Thursday at ten is free, so the receptionist ends up retyping everything and the value evaporates.

When the integration is the whole point and nothing off the shelf can reach your system, custom work earns its price. Even then, the custom part is usually a bridge rather than a whole platform. You buy the AI layer and pay a developer to build the connector, which is a far smaller job than commissioning the lot.

What each option actually costs#

The bottom row is the one people underweight. A subscription you regret costs you one month's notice. A custom build you regret costs you the build, plus the buy you should have made in the first place, plus the months in between.

Run the numbers against the value you expect rather than against each other. If the system recovers ten jobs a year at an average value of $480, that is $4,800 of recovered revenue, which comfortably covers a subscription and does not come close to covering a five figure build. The method for that arithmetic is set out in the ROI walkthrough, and it is worth doing on paper before you take any quote seriously.

The hidden costs nobody quotes you#

On the buy side, the base plan is rarely the bill. Voice agents charge per minute, chat agents often charge per conversation, and both have a fair use ceiling that a busy month will hit. Ask the vendor what a month at twice your current volume would cost. The chatbot pricing breakdown covers the fee structures in more detail.

Setup time is also a real cost even when the tool is cheap. Someone has to write the service list, the prices, the escalation rules and the answers to the questions you field every week. That work is unavoidable in both directions, and it is described in what to feed an AI agent. Budget a day of your own attention for it, because delegating it to someone who does not know the business produces an agent that sounds like it does not know the business.

On the build side, the two costs that surprise people are model changes and staff turnover. Underlying models get updated, and prompts that were tuned against the old one sometimes behave differently. And the developer who built it moves on, taking the context with them. Ask any prospective builder what handover documentation you receive and who maintains it in year two. A vague answer is your answer.

A twenty minute decision you can run today#

Write down the single job you want the AI to do, in one sentence, with the actual verbs. "Answer the phone after hours, take the caller's name, address and problem, and text me a summary" is a job. "Use AI to improve customer service" is not, and it is the reason a lot of first projects go sideways. The five-question test for choosing a first project is a useful filter here.

Then answer two questions. Can you find a product whose marketing page describes that job in roughly your own words? And is there a system it must connect to that you have not confirmed it can reach?

If you can find the product and the connection is confirmed, buy it, configure it properly and give it a quarter. If you cannot find the product, look harder for a week before concluding it does not exist, because the search terms for these tools are inconsistent and the right product often sits under a name you would not guess.

Only when both questions come back negative does a build deserve a conversation. Even then, scope it to the smallest bridge that solves the blockage rather than a platform of your own. The broader context for where this sits in an AI programme is in the overview of AI solutions for small business.

The next step is cheap. Pick the one job, find two products that claim to do it, and book demos with both. Ask each vendor to run your three most awkward customer scenarios live on the call. You will learn more in that hour than in any amount of comparison reading, and if both fail the same way, you have found your genuine case for building.