Build vs buy AI: a decision guide for small businesses

Four options, not two

The build vs buy question sounds binary, but small firms usually have four realistic choices. Laying them out side by side tends to make the decision obvious.

First, use what you already pay for. Microsoft 365, Google Workspace, HubSpot, QuickBooks Online, Clio and ServiceTitan have all added AI features in recent years. Some are useful, some are not, and many owners have never looked. Second, buy a specialist product built for the task, such as an AI receptionist, a document extraction service or a proposal tool. Third, configure and connect: combine a general AI assistant with an automation platform like Zapier, Make or n8n and templates you control. Fourth, build custom: code written for you, calling AI models through an API and integrating with your systems.

Each step down that list adds control and cost. Using what you own is cheapest and least flexible. Custom builds are the most flexible and carry a maintenance bill for as long as you use them. Most firms should work down the list in order and stop at the first option that solves the problem well enough.

What each option really costs

Compare total cost over two or three years, not just the first invoice. Prices change, so check current pricing for any product you consider.

The maintenance line is the one that surprises people. AI model providers retire older models, change pricing and update behavior. Your own systems change too: a new field in the CRM, a new service line, a new price list. A custom build that nobody maintains slowly drifts out of step with the business until someone notices it producing wrong output.

• Features you own: often included or a modest add-on per user. The main cost is the time to evaluate and switch them on properly.
• Specialist product: a monthly subscription, onboarding fees in some cases, and staff time to set it up. Costs rise with seats or volume.
• Configure and connect: automation platform fees, AI seats or usage, and setup time measured in days or weeks. Someone must own it after launch.
• Custom build: design and development, hosting, AI usage, security review, and ongoing maintenance. Plan for maintenance every year, because APIs, models and your own processes change.

When buying is the right call

Buy when the problem is common across many businesses. Scheduling, reminders, call answering, e-signature, invoice follow-up and meeting notes are solved problems. Vendors spread development cost across thousands of customers, fix bugs you will never see, and keep up with model changes. You cannot match that with a one-off build.

Buying also makes sense when the vendor already holds the data. If your matters live in Clio or your jobs in Jobber, the AI feature inside that product can see context an outside tool cannot, without a new integration to maintain.

The risk with buying is fit. A product designed for a 500-person company may be heavy for a 20-person firm, and one designed for a different industry may force awkward workarounds. Trial it on your own real examples before signing anything longer than a month or two.

When building is worth considering

Building, or a substantial custom configuration, earns its cost when three things are true at once:

A typical example is a quoting tool for a specialist contractor with unusual pricing rules, or a document workflow at an engineering firm that combines several systems no product connects. Even then, consider building on top of products you already use, such as an automation platform and your existing CRM, rather than starting from nothing.

• The workflow is valuable: it touches revenue, margin or a major cost, and you can calculate a break-even.
• It is specific to you: your pricing logic, your document formats or your mix of systems means no product fits without heavy compromise.
• It is stable: the process will look broadly the same in two years, so the build will not need constant rework.

A short test before you decide

Answer these questions in writing. If most answers point the same way, you have your decision.

Has anyone checked whether a tool you already own does this? Can you name two products built for this problem, and have you trialed one on real examples? If you built it, who would fix it at 7 a.m. when it breaks? What happens to the process if that person leaves? Could a simpler version, such as a template plus an AI assistant plus a person reviewing, get you most of the benefit in a week?

The last question matters most. In our experience, many custom-build ideas shrink to a configure-and-connect project once someone tries the simple version first. That is a good outcome. It is cheaper, and it teaches you what you would need from a custom build if you still want one later.

Protecting yourself whichever way you go

A few safeguards apply to every option. Keep the system of record, such as your CRM, practice management or accounting system, as the place where data ultimately lives, so you can switch tools without losing history. Run automations and integrations under company accounts, not personal logins. Get documentation: for a product, the data terms and export options; for a build, a plain description of what it does, where the code lives and how to turn it off.

If a tool will score or rank people for hiring, housing, credit, insurance or health care, check whether Colorado's SB 26-189 applies from January 1, 2027. The law places documentation duties on developers and notice duties on deployers, and a custom build can make you both.

Making the decision stick

Write the decision down with the reason, the expected cost and the measure of success, and review it after 90 days. If you bought, check adoption and whether the product actually fits. If you built, check how much maintenance it has needed. Either answer can change your next decision.

InTheory's role in these decisions is to be neutral: we do not resell software, and sometimes the right recommendation is a settings change in a tool you already have. A typical first step is to map the workflow and test the simple version before anyone writes code.

Be wary of sunk-cost thinking in both directions. A product bought on an annual contract that nobody uses should still be retired at renewal, and a custom tool that needs constant fixes should be replaced if a product now covers the need.