Most Australian SMEs asking "should we buy this or build it?" are comparing the wrong two numbers. On one side of the page is an annual licence fee from a vendor's pricing tier. On the other is a quote from a development shop. The two figures look comparable, one is usually much smaller, and the decision gets made in about ten minutes.
The number that actually decides the outcome three years later is neither of those. It is the cost of the gap between what the software does and what your business does — the exports, the re-keying, the spreadsheet that sits alongside the system because the system will not hold that field, the person whose job is partly to be the integration between two applications that do not talk. That gap has a running cost, it compounds with headcount, and it does not appear on either quote.
Why the question is live right now
The buying environment has moved quickly enough that advice written two years ago misreads it. The ABS reported that around 12 per cent of Australian businesses used AI in 2024–25, with 22 per cent of medium-sized businesses and 11 per cent of small and micro businesses doing so, against 35 per cent of large firms. The National AI Centre's more recent tracker puts SME adoption at 43 per cent across the December 2025 to February 2026 quarter, rising to 44 per cent in February 2026, using a broader definition of use.
Read those together and the picture is: a lot of trial, much less production. Which is exactly the condition in which businesses overbuy. You test three tools, you like two, you buy seats for everyone, and eighteen months later you are paying for platform capacity nobody uses while the actual bottleneck — a quoting process that still runs through email — is untouched.
The same research explains why. One SME survey found 23 per cent of businesses remained unaware of AI's potential business applications and 42 per cent had no plans to implement, and another reported 21 per cent still did not know how to use it. The constraint is application knowledge, not budget. Build-versus-buy is really a question about which option gets you to a working process fastest with the fewest permanent liabilities attached.
The costs that show up on each side
Here is the full ledger, not the licence line. Treat this as the checklist you run before either decision.
| Cost category | Buying off the shelf | Building internally |
|---|---|---|
| Direct spend | Per-seat or per-task subscription, usually escalating with headcount and usage | Build cost, hosting, any platform licence underneath |
| Fit gap | Workarounds, parallel spreadsheets, manual re-keying between systems | Low at launch, grows if requirements are not revisited |
| Integration | Connector fees, middleware, or custom work to reach your other systems | Included in scope, but scope is where estimates go wrong |
| Data and compliance | Where the data is hosted, who can access it, what the vendor does with it | Yours to decide, yours to get right |
| Change of direction | Feature requests join a roadmap you do not control | You can change it, but somebody has to |
| Exit | Data export quality, contract terms, migration cost | Ongoing ownership, no exit but no escape either |
| Failure mode | Vendor changes pricing, deprecates a feature, or is acquired | Nobody maintains it after the person who commissioned it leaves |
The two rows that decide most real cases are fit gap and exit. Off-the-shelf software is cheap until you are running it at 70 per cent fit and paying a person to be the other 30 per cent. Custom software is expensive until you notice you have been paying that person for four years.
Illustrative arithmetic, not a quote
Vendor pricing changes constantly and varies by plan, so the following uses invented round numbers purely to show the shape of the comparison. Substitute your own.
A team of 35 on a per-seat internal tool at $70 per user per month costs $29,400 a year, or $88,200 over three years, before integration work. Add one part-time coordinator at 0.4 FTE on $85,000 including on-costs to handle the exports and re-keying the tool does not cover, and the three-year figure becomes roughly $190,000.
A purpose-built internal tool sitting on top of the systems you already pay for might carry a build cost plus a modest platform and hosting line, and removes most of the coordinator's manual work. Whether that wins depends entirely on the build number — but the point is that the coordinator belongs in the comparison, and in most quotes we see, they are not in it.
The reverse case is just as common. If the process is genuinely standard — payroll, accounting, statutory reporting — building is close to indefensible. You would be rebuilding compliance logic that a vendor maintains for you, and inheriting the obligation to keep it current forever.
The line that actually separates the two
Buy the system of record. Build the workflow layer.
Your general ledger, payroll, CRM, practice management or job management system is a system of record. It holds the authoritative version of something, it has compliance obligations attached, and its logic is common to every business in your category. Buy it. Do not build it, do not fork it, do not let anyone talk you into a custom alternative because the vendor's UI is dated.
What sits on top is different. The approval flow that is specific to how your directors delegate authority. The intake form your field crews fill in on a phone at a site. The reconciliation between the job system and the accounting package that currently runs as a Tuesday morning ritual. The dashboard your operations manager wants that nobody sells because nobody else runs your business. These are not products. They are your operating model expressed as software, and no vendor will build them because the addressable market is one.
This is where the middle path lives, and it is where most Australian SMEs end up once they have been through a full evaluation honestly. You keep the systems of record you have. You put a thin, purpose-built layer over the top that handles the parts that are specific to you — an internal tool for the humans, an automation for the machine-to-machine steps, and an AI agent where a step involves reading unstructured text and making a judgement.
The reason this path has become viable for businesses under 200 staff is that the layer no longer has to be built from scratch. Retool gives you an internal application — tables, forms, approvals, role-based access — assembled against your existing databases and APIs rather than written from nothing, and n8n handles the scheduled and event-driven glue between systems. When we do Retool internal tool development for an SME, the substantial part of the work is almost never the interface; it is the permissions model, the exception handling, and the reconciliation logic that decides what happens when two systems disagree about the same record.
That is also the honest caveat. The build is not the hard part. Deciding what should happen when an invoice arrives referencing a job number that does not exist is the hard part, and it takes people who know the business sitting with people who know the tooling.
Where Australian context changes the answer
Two things push local buyers toward the middle path more often than a generic build-versus-buy framework would suggest.
The first is data location. Adoption is visibly slower in sectors carrying compliance weight — one survey found healthcare SMEs held back by compliance concerns and legacy systems, and industry adoption ranged from 45 per cent in health, education and manufacturing down to 6 per cent in agriculture. If client data cannot leave Australia, or cannot leave your own infrastructure, that constrains which off-the-shelf products are even eligible. A self-hosted workflow layer over a compliant system of record is often the only combination that clears the bar.
The second is where the value has actually landed. Australian SME adoption is concentrated in customer and data analysis tools at 27 per cent and productivity tools at 23 per cent — practical, bounded tasks rather than platform-wide transformation. That is an argument for narrow builds against specific processes, not for a large custom system that tries to replace a suite.
Geography matters too. Regional SMEs were found to be 11 per cent less likely to implement AI than metro ones, which usually reflects available technical skills rather than appetite. If you cannot hire a developer within 200 kilometres, "we'll maintain it ourselves" is not a maintenance plan.
A test you can apply this week
For each process you are considering, answer three questions. Is the logic specific to us, or is every business in our industry doing it the same way? If we stopped doing it manually, how many hours a week come back, and whose? If the tool broke on a Friday, what happens on Monday?
Standard logic, few hours, nothing much happens on Monday — buy the cheapest thing that fits and move on. Specific logic, meaningful hours, real consequences on Monday — that is the layer worth building, and it is worth building properly.
The first move, and then the offer
Take one process, and for two weeks have whoever runs it note where the data is re-entered, exported, or checked by hand. Not a full process map — just the touch points. Multiply the time by a loaded hourly rate. That single number is the one missing from every build-versus-buy comparison we are asked to review, and it usually reframes the decision on its own.
When you have it, we will run the comparison properly with you. Put your numbers through the return on investment calculator and we will come back with a scope for the workflow layer over your existing systems, a build figure in AUD, a two-to-four-week delivery window, and a straight answer about whether the payback is there — including the cases where it is not and you should stay on the tool you already have.