What the published ranges say
Collected on 22 October 2026 from Australian vendor sites, the published figures for AI software development look like this. They are reproduced here because the shape matters more than any individual number.
| Tier as published | Range quoted | What the page says it includes |
|---|---|---|
| Proof of concept | $20,000 to $50,000 | One use case, sample data, no production integration |
| Simple or MVP | $15,000 to $80,000 | Depends entirely on which page you read |
| Mid-range | $25,000 to $200,000 | An eightfold spread inside a single tier name |
| Enterprise | $200,000 to $500,000 and above | Outliers quoted beyond $1m |
| Hourly | $100 to $250 per hour | Australian developer rates |
| Annual maintenance | 15 to 20 per cent of build | Usually a footnote |
Look at the mid-range row. One vendor's mid-range starts where another vendor's ends. That is not a market disagreeing about rates, because the hourly rates are broadly consistent across the same set of pages. It is a set of pages using one word for several different amounts of work.
A tier label describes the size of the invoice. It does not describe the work, which is why you cannot find your own project in one.
None of the pages states what its numbers are based on. No sample size, no number of projects, no date on the figures. They are not dishonest, they are just unfalsifiable, and a buyer reading six of them ends up averaging guesses.
The variable that actually moves the number
In practice, the cost of an AI software development project in Australia is driven less by the model and more by the integration surface: how many systems the workflow has to reach into, and how well each of those systems lets itself be reached.
This is the opposite of how the ranging pages work. They put the AI at the centre and treat integration as a line item. On almost every project we have shipped, the model work was the predictable part and the integration was where the estimate moved.
| Integration surface | What it looks like | Effect on cost |
|---|---|---|
| One system, good API | A documented REST API, stable auth, a sandbox | The best case. The estimate holds. |
| Three to five systems, mixed | Two modern APIs, one vendor portal, one CSV export on a schedule | The common case. Expect the integration to be the largest single line. |
| A system with no API | Work is done in a screen a person operates, and there is no supported way in | Changes the project. Either the vendor is brought into the conversation or the step stays manual. |
| A system you do not control | A client's or regulator's portal, changing without notice | Adds permanent maintenance rather than build cost, and it never goes away. |
Counting your own integration surface takes an afternoon and it is the single most useful thing you can do before asking for a quote. List the systems the workflow touches, and for each one write down whether it has a supported API, who owns the credentials, and whether anyone in the building has ever automated against it before. That list is worth more to an estimate than a requirements document.
Three costs that never appear in a published range
The integration you write anyway
This one only shows up on the buy path, which is why a page about development costs never mentions it. An off-the-shelf tool still has to see your data and write its results back somewhere, and unless your systems are the ones it ships connectors for, that connection is custom work you pay for either way. Comparing a licence fee against a build cost without it is comparing two different scopes.
The approval path
If a human has to approve what the system does, and it has to be provable later that they did, that is not a checkbox. It is a record of who was asked, what they saw, what they decided and when, kept somewhere that cannot be edited afterwards. Our workflow systems carry an immutable audit log that captures every action, and building that is real effort that no tier label accounts for. It is also increasingly not optional: from 10 December 2026 Australian privacy policies must describe the automated decisions a business makes, which we have written about in detail, from the software side.
The exit cost
Every system you adopt has a cost to leave, and nobody prices it at the start. On the buy path it is the data you cannot export in a usable shape. On the build path it is a codebase nobody but the original vendor understands. Both are avoidable, and both are cheapest to avoid in the first week by settling repository ownership and export format before anything is written.
Where the money actually went on two builds
Two of the projects we can describe publicly have the same shape, which is itself informative. HBI Australia was running its operations across eight off-the-shelf tools and cut manual handling by 60% after moving to a single platform. For a medical staffing client, getting one doctor from applicant to paid touched eight separate systems, with staff re-keying data at every boundary between them.
In both cases every individual tool worked. The cost was in the gaps between them, and the gaps were staffed by people. That is the pattern worth checking for in your own business, because it changes what you are buying: not an AI feature, but the removal of the boundaries that a person is currently standing in.
It also explains why the integration surface dominates the estimate. A project that replaces eight boundaries is eight integration problems with some model work attached, not one AI project. You can read both in full under our case studies.
Five facts that make quotes comparable
Give every vendor the same five facts and their quotes become comparable, because they are finally quoting the same project. Withhold them and the spread you get back is a measure of how differently each vendor guessed.
- The list of systems the workflow touches, with the API situation for each.
Named systems and versions. Not the category, the actual product and who administers it.
- The volume, as a number per day or per month, and what the busiest day looks like.
A process that runs forty times a day and one that runs forty thousand are different builds even when the logic is identical.
- Where the human checkpoint is, and whether it has to be provable afterwards.
This is the difference between a workflow and a governed workflow, and it can be a third of the build.
- What happens when it is wrong, in your business rather than in principle.
A wrong result that costs an apology and a wrong result that costs a payment produce different architectures and different prices.
- Where the data is allowed to go.
If it cannot leave Australia or cannot leave your tenancy, say so in the first conversation. The OAIC's guidance on commercially available AI products is the reference for that call.
A reasonable way to spend the first dollar
The ABS reported that 12% of Australian businesses used AI in 2024-25, up from around 1% two years earlier, so most organisations asking this question are asking it for the first time and have no internal benchmark to check a quote against. In that position, the cheapest way to get a real number is to buy a small, finished piece of work rather than an estimate.
Scope one workflow, with its real integration surface, that is small enough to reach production. What it costs is then not a tier, it is a measurement, and every subsequent estimate in your business can be checked against it. It also produces working software, which a discovery document does not.
Is a fixed price or time and materials better for AI work?
Fixed price is reasonable where the integration surface is known and the outputs are checkable. It gets expensive where neither is true, because the vendor prices the risk and you pay for it whether or not it occurs. A useful middle path is to fix the price of a first scoped build and decide the rest once there is a measurement.
Why are offshore quotes so much lower?
Usually because of rates, and sometimes because the scope is smaller than it appears. The five facts above are the test: if a quote at half the price covers the same integration surface, the same volume, the same approval path and the same data constraints, it is a genuine price difference. If it does not, it is a different project.
What does ongoing cost actually consist of?
Three things that behave differently. Model and infrastructure usage, which scales with volume. Maintenance of integrations against systems that change underneath you, which is unpredictable and never reaches zero. And changes you ask for, which are new work. The published 15 to 20 per cent figure bundles all three into one number, which is why it rarely matches anyone's actual experience.
Should we build this at all?
Often the honest answer for part of the workflow is no. We have set out a test that produces an answer per step rather than per system in build versus buy for AI software.
How do we compare the vendors themselves?
Separately from the price, and with questions that have checkable answers. Six of them are in choosing an AI development company in Australia.