Why the usual answer does not help
Read the comparisons that rank for this question and they converge on the same three points. It depends. Go hybrid. Pilot before you commit. All three are true, and a reader who arrived needing to make a decision leaves holding the same decision.
The triggers offered for building are abstract: proprietary data, competitive moat, compliance. Nobody can tell whether their data is proprietary enough. A moat is something you identify afterwards. So the advice terminates in a judgement call, which is where it started.
The question is not hard because the trade-offs are subtle. It is hard because everybody asks it about the wrong thing.
The wrong thing is the system. Nobody buys or builds a system in one act, and no real workflow is uniformly generic or uniformly special. A quoting process might be entirely standard for four of its steps and completely particular to your business for the fifth, and the fifth is the one that decides whether a bought tool fits.
The unit is the step
Write the workflow out as steps, in the order they happen, at the level of one action by one person or one system. Most real processes come out at between six and fifteen. Then mark each step independently, because each one has its own answer.
- Does this step happen the same way in other businesses?
Extracting fields from an invoice is the same everywhere. Deciding which of your four entities it gets coded to is not.
- Does it touch a system a bought tool already connects to?
Check the vendor's actual connector list rather than assuming. This is the step where most buy decisions quietly become build decisions.
- Does anything here have to be provable afterwards?
If yes, the step needs a record that the tool may not keep in a form you can produce.
- If this step is wrong, who finds out and how?
A step whose errors surface immediately is far safer to buy than one whose errors surface in a quarterly reconciliation.
Four answers per step, and the pattern is usually obvious once it is on paper. Generic steps touching connected systems with visible errors are bought. Steps that are particular to your business, or that reach into something nobody connects to, or that have to be defensible, are built. The hybrid everyone recommends then falls out of the exercise instead of being an aspiration.
The boundary test
A mixed workflow needs somewhere for the bought part to stop and the built part to start, and the handover point is what determines whether the hybrid works or becomes a maintenance problem.
A clean boundary has three properties. The data crossing it has a defined shape that you control. The crossing is observable, so when something goes wrong you can tell which side it went wrong on. And either side can be replaced without touching the other. If you cannot describe the boundary in those terms, you do not have a hybrid architecture, you have two tools that happen to run near each other.
This is a large part of what integration and orchestration work actually is, and it is a service in its own right rather than a line item tacked onto the end of a project. The boundaries are where the value and the failures both live, and a hybrid only pays off when somebody owns them.
Four constraints that force a build
These replace proprietary data and competitive moat with things you can check this week, against systems you already run. Any one of them, present at a given step, decides that step.
| Constraint | How to check it | Why a bought tool struggles |
|---|---|---|
| A record that must outlive the vendor | Ask how long you must be able to produce this, then compare it to your contract term | Export is usually possible and usually unusable. The record survives, its context does not. |
| An approval that must be provable | Ask whether you could show who approved what, on what information, two years later | Most tools log that an approval happened, not what the approver was shown. |
| A system with no supported API | Try to find the vendor's API documentation. If a person operates a screen, that is your answer | Connector lists are finite. A tool cannot reach a system it has no way into. |
| A rule that changes faster than the vendor ships | Count how many times the rule changed in the last two years | A quarterly rule change against an annual release cycle means you are permanently out of date. |
The third row is the one that most often decides a whole project in Australian businesses, because the systems that run the operation are frequently older than the systems that run the marketing. The fourth decides it in regulated work.
Constraints can also force the shape of a build rather than just its existence. In a SharePoint access governance build for an Australian resources business, a rule against holding documents outside SharePoint meant the governance was built inside SharePoint, with approval routing that finds its own approver and permissions that expire on a clock. The constraint was known first and the architecture followed from it.
What the buy path actually costs
Buy-side comparisons price a licence. Two costs are missing from that, and they are the two that decide most of these cases once someone writes them down.
The first is the integration you write anyway. A bought tool has to see your data and write its results back, and unless your systems are on its connector list, that connection is custom work with a custom price. It is not an argument against buying. It is an argument against comparing a licence fee to a build cost as though they covered the same ground.
The second is the exit cost. Everything you adopt has one, and it is never quoted. Ask for a sample export before you sign, not a promise of one, and look at whether the decisions and approvals the tool generated come out in a usable shape, because those exist nowhere else. We go into both in more detail in what AI software development costs in Australia.
When every tool works and the stack still fails
The clearest evidence that the system is the wrong unit comes from workflows where the per-system answer was buy and every per-system answer was correct.
HBI Australia was running its operations across eight off-the-shelf tools, every one of which worked, and the cost was in the gaps between them. For a medical staffing client, getting one doctor from applicant to paid touched eight separate systems, and every boundary between them was somebody re-keying data.
Nobody made a bad purchase in either business. Eight sensible decisions were made one at a time, and the thing that failed was not any of the eight, it was the seven boundaries nobody owned. That failure is invisible to a build-versus-buy analysis conducted per system, which is the whole point. It is immediately visible in a step-by-step pass, because the re-keying steps are steps, and steps get marked.
Both are written up under our case studies, including what replaced them.
What to do with the result
The exercise ends with a marked-up list of steps rather than a verdict, and that list is directly useful in three ways.
- It tells you what to pilot.
Pilot the built steps, not the bought ones. The bought steps are a trial account and an afternoon. The built steps are where the uncertainty is.
- It makes quotes comparable.
Every vendor is now quoting the same scope, because the scope is a numbered list of steps rather than an outcome.
- It survives the decision.
When a step's constraints change, you re-mark one row instead of reopening the whole question. The annual review everybody recommends becomes ten minutes.
The ABS reported that 12% of Australian businesses used AI in 2024-25, up from around 1% two years earlier, so most organisations running this exercise are running it for the first time. Doing it at the step level is more work than reading a comparison table, and it is the only version that produces an answer you can act on.
Is not the hybrid answer the same thing?
It is the same conclusion reached without a method. Everyone recommends a hybrid, and almost nobody says how to divide the work, which leaves the division to whoever is selling. Marking steps is the division.
What if a bought tool covers nine steps out of ten?
Then buy it, and treat the tenth as its own small build with a clean boundary. The failure mode to avoid is bending the nine to accommodate the one, which is how businesses end up configuring a generic tool for months against data it was never designed for.
Does the automated decisions obligation change this?
It raises the cost of steps that decide something about a person without a human in the loop, because from 10 December 2026 those have to be described in a privacy policy. Whether a bought tool can tell you what it decided and on what basis becomes a procurement question. We have written about what that requires of the software in instrumenting automated decisions.
How do we judge a vendor once we know what we need built?
With questions that have checkable answers rather than criteria every firm passes. Six of them, taken from the government's own adoption guidance, are in choosing an AI development company in Australia.