Build Versus Buy for AI: The Honest Answer for a Business Under Twenty People

Someone on your team has just found an AI tool that does something close to what your business needs, and someone else has said "we could probably build that ourselves." Both of them are half right, and the arithmetic in this article will tell you which half.

The honest answer, for almost every business between five and a hundred people, is buy. Not because building is impossible, but because building is a decision to become a small software company on top of whatever business you already run. That is a real cost, it does not stop once the tool works, and most owners never see it written down before they say yes. This piece shows you the working, sets out the three conditions under which building is actually defensible, and gives you a way to read a vendor proposal properly before you sign it.

What building actually costs once it works

The cost that gets quoted for a custom build is almost always the cost to get it working. It is never the cost to keep it working, and that second number is the one that determines whether building was the right call.

Start with the wage. The median full time earnings for a software developer in Australia are $131,924 a year, or $2,537 a week, according to Jobs and Skills Australia's occupation profile, which draws on the ABS Survey of Employee Earnings and Hours. Add the superannuation guarantee, now 12 percent of ordinary time earnings under the final legislated step confirmed by the ATO from 1 July 2025, and one developer costs a business roughly $147,755 a year fully loaded, before payroll tax, leave loading, a laptop, software licences or the cost of finding them in the first place.

Now put that against what a typical business actually has to spend on technology. Deloitte's Global Technology Leadership Study found average technology budgets equivalent to 5.49 percent of revenue. For a business turning over $3 million a year, that is a total annual technology budget of roughly $164,700, covering every laptop, every software seat, every support contract and every agency retainer the business runs. One developer's fully loaded wage alone would eat almost all of it, leaving nothing for hosting, security patching, model updates when the underlying AI provider changes its terms, or the ordinary software the rest of the business still needs.

Even a lighter commitment adds up. If the tool needs half a day of a developer's attention each week once it is live, that is roughly a tenth of a full time role, or about $14,776 a year in labour alone, before hosting and compute. That is the number that does not appear in the excitement of the build, and it is the number that turns a clever internal project into a permanent line item nobody budgeted for.

The three conditions under which building is defensible

Building is not always wrong. It is defensible under three specific conditions, and if your situation does not meet at least one of them, stop and buy.

The first is that the workflow is genuinely yours, not a generic task with ten vendors already selling it. If the process is the thing that actually wins you work, something proprietary to how you quote, schedule or serve clients that a competitor could not simply subscribe to, then a generic tool will never fit it well enough to matter. The second condition is that you already carry technical capability inside the business, a developer or systems person whose time is already paid for and whose day includes maintaining internal tools. In that case the marginal cost of the build is close to zero rather than a new $147,755 commitment, because you are not adding headcount, you are redirecting existing capacity.

The third condition is scale over time. If the volume is high enough and the need is long lived enough, the built tool's cost per transaction can genuinely undercut a subscription that charges per seat or per usage as you grow. This is the one condition you can actually prove with a break even calculation: add up the build cost plus every year of maintenance, divide by the number of years you expect to run it, and compare that annual figure against what a subscription would cost across the same volume over the same period. If a vendor cannot show you that arithmetic in their own proposal, do not assume it favours the build. Do the sum yourself before you commit.

How to read a vendor proposal against a build

A vendor proposal should be read the same way you would read a lease, line by line, not as a single number. Separate the licence or seat fee from the setup and integration fee, separate both of those from any ongoing support contract, and separate all of that again from whatever content or configuration work the tool needs to be useful to your business specifically. Each of those lines should sit as a small fraction of the total technology budget you already have, not as a new category competing against wages, rent and insurance for attention.

Compare that fraction against the fully loaded developer wage above. A subscription that costs a genuine fraction of what one developer costs to employ for a year is doing the arithmetic in your favour before you have even measured a result. If a vendor's proposal, once every line is added up, starts approaching a meaningful share of what Deloitte's benchmark says your whole technology budget should be, that is the moment to ask harder questions, not sign faster.

Measuring the pilot, and the value of a stop

Whichever way you go, run it as a pilot with four numbers agreed before you start: cycle time (how long the task takes from start to finish), error rate (how often the output needs correcting by a person), revenue per enquiry where the tool touches sales or quoting, and cost per output once wages, subscriptions and any build maintenance are all included. These four numbers, tracked weekly, tell you the truth faster than anyone's opinion of the tool.

The cost of a wrong decision is not the subscription fee or the build invoice. It is the months spent running a tool that quietly makes cycle time worse, error rate higher, or cost per output climb, while nobody wants to be the one who says stop. A defined stop point, agreed before the pilot starts, at a fixed cost and a fixed date, is worth more than any feature list. If the four numbers have not moved by the date you agreed, switch it off and take what you learned into the next decision.

If you are weighing a genuine build against a subscription right now, get the arithmetic checked before you commit either way. Our build and operate service exists for exactly this decision, to run the numbers against your actual revenue and wage costs, tell you honestly which side of the three conditions you sit on, and set the stop point before anyone spends a dollar.