Should a Small Business Build or Buy an AI Tool?

Buy when the tool is a commodity, build when the tool encodes something specific about how you work. That is the honest answer for most small businesses, and the reason it gets ignored is that the second half used to be unaffordable. It is not any more, which has quietly moved the line for one particular category of software. Here is the arithmetic, the questions that override it, and where the line sits now.

Run the number before the argument

Most build-versus-buy debates are conducted entirely in adjectives. Do the sum first, with round illustrative figures, and the conversation gets shorter.

Say the tool you are considering costs 40 per user per month and you have six people who need it. That is 2,880 a year, 8,640 over three years. Now price building it: the build itself, plus the part everyone forgets, which is that software you own needs attention every month for as long as you use it.

A realistic maintenance figure for a small internal tool is two to four hours a month, forever. Not because it breaks constantly, but because dependencies age, a provider changes an API, someone needs a new field, and a browser update breaks a layout. At a notional 60 an hour that is 1,440 to 2,880 a year of real cost, whether you pay it in cash or in your own evenings.

Which produces the uncomfortable result: for a six seat commodity tool, building rarely wins on cost alone, even when the build itself is nearly free. The maintenance line eats the saving. Buying wins on cost, and the reasons to build have to come from somewhere else. The general framework for pricing this kind of decision is in how much a small business should spend on AI tools.

Three questions that override the maths

Cost decides the boring cases. These three decide the rest.

Does it encode something only you do? If your quoting process has fourteen rules that exist because of things that went wrong in 2019, no vendor sells that. You will either bend your process to the software, which has its own price, or maintain a spreadsheet beside the tool, which means you are already running a homemade system with worse ergonomics.

How bad is it if this stops existing? Vendors get acquired, change pricing, and sunset products. If the tool is where your customer relationships live, that dependency is a real business risk, and owning it has value that never shows up in a per-seat comparison. If it is a transcription tool, switching costs you an afternoon and the risk is negligible.

Will more than three people rely on it? A tool one person uses can be scrappy. Once four people depend on it, you have inherited an internal product: onboarding, permissions, someone to ask when it misbehaves. That is where homemade tools quietly become expensive.

Where the line sits by category

The category that genuinely changed

Internal glue used to lose to buying for a boring reason: a tool worth 3,000 of your time was worth 15,000 to build, so you bought a 40 a month product that did 60 percent of the job and lived with the gap. Multiply that across a business and you get the familiar situation of eleven subscriptions, each doing part of what you need, and a person whose job is partly to move data between them.

When the build cost drops far enough, the 60 percent fit stops being good enough to accept. That is the actual shift. It is not that building is free, because maintenance never is. It is that the threshold at which a specific process is worth encoding has come down, so tools that were never worth commissioning now are.

The honest caveat: this applies to internal tools where you are the only user who matters. Customer-facing software still carries support, uptime and security obligations that no build speed changes. A useful cost comparison for that case is in AI app builder versus hiring a developer.

A middle path most businesses skip

Build the thin thing first. Not the tool, the smallest version that proves the process is worth encoding: one form, one automation, one report. Run it for a month. If it gets used daily, you have justified the build and learned the requirements for free. If it does not, you have spent a day discovering that the problem was not worth solving, which is the cheapest possible outcome.

Choosing which process to start with is its own decision, and which tasks to automate with AI first sets out how to rank them. Whatever you pick, agree in advance what success looks like, or you will be having the same argument in six months with better graphics. Measuring AI ROI for a small business covers what to actually track.

Frequently asked questions

Is it cheaper to build an AI tool than to buy one?

Often on day one, rarely over three years, once you price maintenance at a few hours a month. Build for fit and control, not to save on subscriptions, because the subscription is the visible cost and maintenance is the invisible one.

What if we build it and the person who built it leaves?

That is the strongest argument against building, and it is answerable. Insist on a written README, standard technology rather than anything exotic, and credentials held by the business rather than an individual. If those three things are missing, you do not own a tool, you own a dependency on a person.

Can we start with a subscription and build later?

Yes, and it is usually the right sequence. Buying first teaches you what you actually need, at a low monthly cost. The only thing to protect is your ability to leave: check on day one that you can export your data in a usable format, before it becomes a year of records you cannot retrieve.

How do we know a process is worth encoding?

It happens weekly or more, it has rules someone can state out loud, and getting it wrong has a visible cost. If a process fails any of those three, it is not ready to become software, whoever builds it. Wider guidance on where to start is in our AI for small business pillar.