What custom software and ERP actually cost in Australia

A straight answer to the question everyone asks and few answer honestly — what you'll really pay, what drives the number, and where the money goes long after launch.

Aussie Made: Support, Strategic Consultancy and Development

"How much does custom software cost?" is the first question we get asked, and it's the one most developers dodge with "it depends." It does depend — but that's not an answer you can plan a budget around. So here's a straight one: the honest ranges, what pushes a project to the top or bottom of them, and where the money goes long after launch. We've been scoping and building this kind of work in Australia since 2001 — custom applications, ERP and data projects — so these are real numbers, not brochure figures.

One warning before the numbers: anyone who quotes you a firm price before understanding your problem is guessing. Treat the ranges below as a way to place yourself in the right ballpark — not as a quote.

The short version

Most custom projects in Australia fall into three broad bands. Where you land depends far less on "how many screens" and far more on how many moving parts your business has.

Project Typical range What it looks like
A focused tool $15k – $50k One team, one job — a booking system, an inspection app, a quoting tool. Does one thing well, with few or no integrations.
A business system $50k – $150k Several connected workflows, a handful of integrations, and different types of user — a custom operations platform, a customer portal, a field app feeding a back office.
A company-wide platform or ERP $150k + Touches most of the business, migrates years of data, and ties finance, inventory and operations together. Large rollouts run well past this.

What actually drives the number

The gap between the bottom and the top of a band is mostly these six things:

  • Integrations. Every other system you need to talk to — accounting, payments, a supplier's API, an ageing database — is a small project in its own right.
  • Users and roles. One kind of user is simple. Admins, managers, customers and field staff, each seeing different things, is not.
  • Data migration. Getting years of messy data out of the old system and into the new one cleanly is routinely underestimated — sometimes it's the single biggest line item.
  • Compliance and security. Regulated work — health, finance, government — carries real, non-optional cost, and it's far cheaper built in than bolted on.
  • Platforms. Web is one build. Add native iOS and Android apps and you've roughly multiplied a chunk of the work.
  • The long tail. The last 20% — the edge cases, the "what happens if…", the reports nobody mentioned upfront — often costs as much as the first 80%.

ERP is its own animal

ERP deserves its own note, because the sticker price is the part people worry about and rarely the part that hurts. An ERP touches how the whole business runs, so the real cost sits in three places most quotes gloss over: migrating and cleaning years of data, integrating the systems you're keeping, and change management — getting your team to actually work the new way.

There's also a fork in the road worth naming early: do you configure an existing ERP platform to fit, or build custom around your own process? It's usually the single biggest lever on the final bill — we wrote a separate honest guide to exactly that decision: Build, buy or configure?.

The costs that show up after launch

Here's the line item that quietly turns a good decision into a bad one when it's ignored: software isn't finished at launch. Plan for roughly 10–25% of the build cost each year to keep it healthy — hosting, security patches, support, and the improvements you'll want once real people are using it.

Skip that and you don't save the money; you defer it, and it comes back bigger. Over the five years you'll actually use the thing, ongoing costs often rival the original build.

The number that matters isn't the build price. It's the total over the years you'll actually run it.

How you'll be charged

Three common models, and when each earns its place:

  • Fixed price. A set price for a set scope. Comforting — but only as good as the scope it's built on, and it makes changes expensive. Best for small, well-understood projects.
  • Time & materials. You pay for the work as it happens. More honest for complex builds where the path can't be fully known upfront — but it needs trust and real visibility.
  • Discovery first. The sensible middle: pay for a short, fixed-price scoping phase that produces a real plan and a real estimate, then choose how to build from there.

The pattern worth insisting on is that last one: a paid discovery phase before anyone commits to a build price. It's the cheapest money you'll spend on the whole project, and it's what turns "it depends" into a number you can take to your board.

How not to overpay — or under-scope

  1. Start with a paid discovery. A firm quote without one is a guess dressed up as a number.
  2. Be wary of the cheapest quote. It usually means the scope is thin — and the gap comes back later as change requests, at a worse price.
  3. Build the smallest useful version first. An MVP that solves the core problem teaches you more than any spec, and de-risks the spend before it grows.
  4. Own your code. Whatever you pay to build, make sure you own the result. It's an asset, not a rental.
  5. Budget for after launch from day one. If a proposal is silent on support and maintenance, that's a red flag — not a saving.

Want a real number for your situation?

That's how we scope every job — a straight ballpark early, a paid discovery to make it real, and an honest word if we think the cheaper path is off-the-shelf. When we do build, you own it, it runs on Australian infrastructure, and we're here to support it long after launch.

Tell us what you're trying to fix and we'll give you an honest range for your situation — not a figure pulled from the air.

Get an honest estimate · 1300 853 868