Build vs buy AI: a decision framework for mid-market

The build vs buy AI decision, for most Australian mid-market firms, resolves faster than vendors would like you to believe: buy or configure an existing product for anything that is a commodity capability, and build custom only where the work is a genuine competitive edge that no product serves well. That single distinction — commodity versus edge — settles the majority of cases. The contrarian part is what follows from it. The choice between custom AI and off-the-shelf tools matters far less to your outcome than whether your data is ready and your governance holds. Firms lose more money to unready data and absent oversight than they ever save by picking the "right" side of the build-or-buy line.

This article gives you the framework we use with mid-market clients, the three real options most people collapse into two, and the dimensions that should actually drive the call.

Three options, not two

"Build vs buy" is a false binary. There are three distinct paths, and most mid-market firms confuse the middle one for the other two.

Buy or configure. You adopt an existing product — Microsoft 365 Copilot, a vendor's document-processing tool, a purpose-built vertical SaaS — and configure it to your context. You write no application code. Your effort goes into rollout, permissions, prompt patterns, and change management. This is the right default for capabilities that dozens of other firms need in exactly the same shape: drafting assistance, meeting summaries, general knowledge retrieval, standard OCR.

Integrate via API. You build a thin application layer on top of a foundation model or a specialist API. The intelligence is bought; the workflow, the data plumbing, and the business logic are yours. This is where most genuinely useful mid-market automation lives — a retrieval assistant over your own documents, a classifier wired into your intake queue, an agent that drafts from your templates. You are not training models. You are assembling bought components into something specific to your process.

Build custom. You develop bespoke logic — a trained model on your proprietary data, a heavily engineered pipeline, an application whose behaviour is a real differentiator. This is the smallest category and the most misused. Building is justified when the capability is central to how you compete and no product serves it, not because a demo looked impressive.

The common error is treating an API integration as either "buying" (so nobody plans for the engineering and data work it needs) or "building" (so it gets over-scoped into a multi-quarter custom project). Naming it as its own path prevents both mistakes.

The dimensions that should drive the decision

Five dimensions decide the call. Score your use case on each before you look at any vendor.

Differentiation. Does this capability change how you win business, or does every competitor need the same thing? Commodity capabilities should be bought. You gain nothing by building your own meeting-summary tool. Reserve building for the narrow set of tasks where doing it better than rivals is worth real money.

Data sensitivity. Where does the data go, and who can see it? A public-facing marketing assistant and a system handling client financial records or patient information sit at opposite ends. High sensitivity does not automatically mean build — many products offer strong data-residency and isolation guarantees — but it raises the bar on what you must verify before you buy, and it makes the contract terms matter as much as the features.

Cost at scale. Per-seat and per-call pricing that looks trivial in a pilot can dominate your run-rate at full volume. Buying is cheaper to start and often cheaper to run for modest usage. At high, predictable volume, an integration or build can be materially cheaper per unit — but only if you count the engineering and maintenance, not just the inference. Model the cost at your real projected volume, not the pilot's.

Vendor lock-in. How hard is it to leave? Lock-in comes through proprietary data formats, embedded workflows your staff rebuild their day around, and pricing that ratchets once you depend on the tool. Configuration lock-in is usually mild and acceptable for commodity needs. Deep lock-in on a core process is a strategic exposure, not a line item.

Who maintains it. Every option needs an owner. Buying pushes model upkeep, security patching, and capability improvements to the vendor — you own configuration and adoption. Building means you own everything: the pipeline, the monitoring, the model drift, the incident response, for the life of the system. Mid-market firms consistently underestimate this. A custom build is not a project you finish; it is a system you keep alive.

The decision framework

Use this table as a first pass. It resolves most cases; the genuinely hard ones sit in the middle and warrant a proper assessment.

Dimension	Lean Buy / Configure	Lean Integrate (API)	Lean Build custom
Differentiation	Commodity need every firm shares	Standard capability, your specific workflow	Core competitive edge, no product fits
Data sensitivity	Low–moderate; vendor guarantees suffice	Moderate; you control the data layer	High; proprietary data is the asset
Cost at scale	Low or unpredictable volume	Steady volume, per-call economics favour it	Very high volume where unit cost dominates
Vendor lock-in	Acceptable for commodity function	Portable — swap the model behind your layer	You own the stack end to end
Who maintains it	Vendor maintains; you configure	Shared: vendor model, your application	You maintain everything, indefinitely
Time to value	Days to weeks	Weeks to a few months	Months, with ongoing cost
R&D Tax Incentive	Rarely eligible	Sometimes, for novel integration work	Often eligible for genuine technical uncertainty

Read the table honestly. If a use case scores "Buy" on differentiation and cost, the fact that it could technically be built is irrelevant — building it is a waste of senior engineering time and future maintenance load. Reserve your build capacity for the row where differentiation is genuinely high.

Why the build/buy choice is not what decides success

Here is the part most decision frameworks omit. We have seen well-chosen off-the-shelf tools fail and well-scoped custom builds succeed, and the deciding factor was almost never the build-or-buy call itself. It was two things underneath it.

The first is data readiness. A bought tool pointed at inconsistent, inaccessible, or stale data produces the same disappointing results as a custom model trained on the same data. Configuring Copilot over a document estate nobody has curated gives you confident answers drawn from the wrong source of truth. The data problems that sink custom builds sink purchased tools just as reliably — they are simply less visible until rollout. We cover this pattern in detail in why data infrastructure is the real cause of AI pilot failure.

The second is governance. Who approves what the system is allowed to do? How are its outputs checked? What happens when it is wrong, and who is accountable? Under the Privacy Act 2026, APRA CPS 230, and the Voluntary AI Safety Standard, these are not optional for many mid-market firms. A governance-first posture is what keeps a pilot from stalling in proof-of-concept purgatory — the state where a system works in a demo but can never be trusted into production because nobody defined the controls. Buying does not exempt you from this; it changes who holds which control, not whether the controls must exist.

So the honest sequence is: get the data ready and the governance defined first, then make the build-or-buy call. A firm that does this will succeed with either choice. A firm that skips it will fail with either choice, then blame the choice.

The R&D Tax Incentive angle for genuine builds

When a custom build is justified, the R&D Tax Incentive can change its economics. Eligible R&D activities attract a refundable tax offset — 43.5% for companies under the relevant turnover threshold — against expenditure on work that involves genuine technical uncertainty resolved through systematic experimentation.

The nuance is the word genuine. Configuring a product is not R&D. Wiring a well-documented API into your workflow is usually not R&D. Developing a novel model or a technically uncertain pipeline where the outcome could not be known in advance may well be. Designing the build so that eligible activities are structured and documented from the start — rather than reconstructed at claim time — is where the value is protected. This favours building only where a real technical unknown exists, which is the same place building was justified anyway. The incentive rewards the builds you should be doing and does nothing for the ones you should have bought.

Definitions and common questions

Is building always more capable than buying? No. Products backed by large vendors often exceed what a mid-market firm can build and maintain, particularly for commodity capabilities. Building wins on fit and control for edge cases, not on raw capability.

Does buying mean no engineering work? Rarely. Configuration, permissions, data preparation, and rollout are real work. The middle path — API integration — is explicitly an engineering effort and should be planned as one.

What is vendor lock-in, practically? The cost and difficulty of switching away — through data formats, embedded workflows, and pricing dependence. Mild lock-in is an acceptable trade for commodity needs; deep lock-in on a core process is a strategic risk to weigh deliberately.

Who owns the IP and the data in each option? In a build, you own both. In an integration, you own your application and data while the model provider's terms govern inference. In a bought product, the vendor's contract governs data handling and any IP in the tool. Read these terms before, not after.

Should data readiness really come before the build/buy decision? Yes. It determines the outcome more than the choice does. See our work on what AI automation delivery involves for how we sequence data, governance, and delivery.

Where to start

If you are weighing build vs buy across several use cases, the fastest way to avoid an expensive wrong turn is to assess each one against differentiation, data sensitivity, cost, lock-in, and maintenance before any vendor conversation — and to check whether your data and governance can support any option at all. That is precisely what an AI Readiness Audit produces: a clear, use-case-level recommendation on buy, integrate, or build, grounded in the state of your data and controls rather than in a vendor's demo.

Talk to us about a readiness audit and we will give you a defensible decision, not a sales pitch.