Build vs buy AI: the answer just changed for small firms

For years the build-or-buy question had a boring answer: unless you employed developers, you bought.

Coding agents have changed that answer. Tools such as Anthropic's Claude Code and OpenAI's Codex write, run and fix software from a plain-English brief. That means a small firm without a developer can now build a working tool of its own, and trying costs a day or two of someone's time.

So our advice is no longer "buy, full stop". For simple tasks, try a build where it is cheap and safe to do so, because the attempt teaches your team more about AI than any demo. For complex work, buy a mature product that already does the job well. And when nobody sells what you need, building your own is the right answer.

This post is for any leader weighing the two. We will look at what changed, what has not, where each path wins, and a five-part test you can run on any candidate project.

What changed: building stopped needing a developer

A coding agent is an AI tool you brief in plain English. Ask for "a tool that pulls the numbers from our three trackers into one Monday summary". The agent writes the software, runs it, finds its own errors and fixes them while you watch.

Professional developers adopted these tools first, and fast. In Sonar's 2026 State of Code survey of 1,149 developers, 25% already use agentic AI tools regularly and another 39% have experimented with them.

The more interesting shift is who comes next. Anthropic's 2026 Agentic Coding Trends report names non-technical teams building their own tools as one of the year's defining trends. Anthropic's own lawyers are the example: one, with no coding experience, built self-service tools that automate parts of contract review.

The same report finds that about 27% of AI-assisted work is work that would never have been done at all, because before agents it was not worth anyone's time.

That last figure is the point for a small firm. The tools you always wanted but could never justify commissioning are suddenly buildable on a quiet afternoon. Think of the invoice-renamer, the three-tracker summary, or the checklist that fills itself in.

What has not changed: software you build is software you must look after

There is another side to this. The same developers who adopted these tools describe AI as a much better "explainer" and "prototyper" than a "maintainer" or "refactorer", in Sonar's words. Nearly all of them, 95%, still spend real effort reviewing and correcting what it produces.

In plain terms: agents are very good at making a new thing that works today. They are far less reliable at keeping it working as things change around it.

Things do change. The AI model your tool was built on gets switched off by its maker. The file store it reads from moves. The person who built it, and understands it, leaves.

None of this is a reason not to build. It is a running cost, and it means every tool you build needs a named owner and a monthly review, the same discipline we describe in why your AI pilot didn't scale.

A first build belongs on safe ground: no client data, nothing a deadline depends on, and a human check on anything that goes to a client. Learn on the low-stakes work.

Where buying still wins

For common workflows, the market got there before you. In Menlo Ventures' latest annual survey of 495 US enterprise AI decision-makers, 76% of AI use cases are now bought rather than built. For most common tasks a tested product already exists.

Proposal drafting, meeting notes, bookkeeping prep, email handling: these are crowded product categories. A vendor has already built the tool, tested and improved it across thousands of customers, and priced it below what your own hours cost. Rebuilding commodity software with an agent is possible now, and still a poor use of your time.

If a mature product does the job, buy it and spend your effort on getting people to use it and fitting it into how you work, because that is where the return comes from. That is the ground we cover in how to choose an AI use case, and the procurement questions still apply to anything you buy.

Where building shines

Truly niche workflows are where building wins. If your firm produces a report format nobody else uses, reconciles two systems nobody else combines, or runs a checking step unique to your niche, no vendor is going to build it for you. The market is too small for a product to exist.

In those cases, your build is not competing with a polished product. It is competing with doing the job by hand, and it usually wins.

The second reason to build is skills. A team that has built one small tool, even a rough one, understands AI differently afterwards. They write sharper briefs, review output with better judgement, and ask vendors harder questions.

Even a tool you retire after three months leaves those skills behind. We see it in practice: the firms most confident with AI are usually the ones that have made something with it. There is more on that pattern in experts are your best AI users.

The build-vs-buy test

Here is how we now make the decision: three questions before you start, and two checkpoints for as long as you use the tool. We call it the build-vs-buy test.

Before you start, ask:

1. Does a mature product already do this? If yes, buy it. Do not rebuild commodity software, however easy the agent makes it.
2. Is the workflow genuinely niche? You have searched and no real product exists. This is where self-building shines. Build.
3. Is it cheap and safe to try? That means a day or two of someone's time, no client data, and nothing critical depending on it. If yes, try the build even when you are unsure. What you learn is worth a day of someone's time.

Every month the tool survives, ask:

4. Does it still have a willing owner? That means someone on the payroll who fixes it when it breaks and knows how it works.
5. Is it still saving more time than it takes to maintain?

The rule: two consecutive monthly "no" answers mean it is time to switch to a bought tool. Switching is not a failure. You keep what you learned about the process, you choose a replacement with far better judgement, and the team keeps the skills.

Applied to two candidate projects at a fictional eight-person consultancy, the test looks like this:

The proposal tool fails at question one: the category is crowded, and a bought product takes an afternoon to set up with the firm's house style and boilerplate. The Monday summary passes all three: nobody sells it, and an agent can build it in a day. If you want a second pair of eyes on a bigger call, it helps to know what an AI consultant costs before you commission anything.

Frequently asked questions

Can a firm without developers really build its own software now? Yes, within limits. Coding agents such as Claude Code and Codex turn a plain-English brief into working software, and Anthropic's 2026 trends report expects non-technical teams to do more of exactly this. Start on low-stakes internal work, keep client data out of a first build, and have a human check anything that reaches a client.

Should a small business build or buy AI tools? Both, for different jobs. Buy for common workflows where a mature product exists, because the vendor has already tested and refined it on thousands of customers. Build for genuinely niche workflows no product serves, and for the skills the attempt teaches your team. The build-vs-buy test above settles any specific case.

What if the tool we built keeps breaking? Switch to a bought tool and treat the build as cheap education, because that is what it was. The monthly checkpoints exist for exactly this call. If, two months running, there is no willing owner or it costs more time than it saves, switch. You come back to the market knowing precisely what you need.

---

Are you weighing a specific build against a subscription right now? Book a call and we will run the build-vs-buy test with you on the real project, and give you a straight answer either way.