What custom software costs in Australia and why the range is wide

Custom software costs swing wildly because the phrase covers wildly different work. A small internal tool is nothing like a multi-tenant SaaS product. A workflow app with one integration is nothing like a regulated platform carrying permissions, audit logs, reporting and payments.

So “what does an app cost?” is the wrong question. Ask what the software needs to own.

The confusion isn’t the buyer’s fault, either. Ring three developers with the same one-paragraph idea and you’ll get quotes spanning a 5x range, not because two of them are dishonest, but because each one silently filled in the gaps of your paragraph with different assumptions about users, permissions, integrations and polish. The paragraph is the problem. Until the scope is pinned down, every number anyone gives you is a guess about what you meant, and the wide market range you’ll find on Google reflects exactly that. We’ve pulled apart why software quotes vary so much separately; this article is about what the numbers actually look like and what moves them.

Scope drives the first number

A simple prototype might prove an idea or kill off one stubborn spreadsheet. A production business app needs authentication, roles, validation, backups, error handling, monitoring and documentation. A platform that external customers log into needs more care again.

Every one of those layers costs money because every one of them takes risk off the table. Skip them and you get a smaller first invoice and a bigger bill later.

The jump between those tiers is the part buyers underestimate. The same “job tracking tool” can be a two-week internal build used by five trusted staff, or a customer-facing system where a stranger’s mistake or malice can’t be allowed to break anything, and the second version costs several times the first even though the screens look similar. What moved isn’t the features. It’s the standard of care: a customer-facing system has to handle bad input gracefully, keep every tenant’s data walled off from every other’s, survive being hammered, and leave an audit trail when something is disputed. When a quote seems surprisingly cheap for what you described, this is usually the layer that’s been quietly left out, and you find out at the worst possible time.

Useful starting budgets

For Australian businesses planning a serious software project, these are sensible starting points:

• Scoping and architecture sprint: from A$3,500 ex GST.
• Prototype or proof of concept: from A$7,500 ex GST.
• Focused automation or AI workflow: from A$7,500 ex GST.
• Integration, data and reporting work: from A$10,000 ex GST.
• Website rebuild or performance rescue: from A$6,500 ex GST, with full rebuilds from A$12,000.
• Custom software, apps and portals: from A$20,000 ex GST.
• Larger SaaS products, regulated systems or multi-tenant platforms: from A$180,000 ex GST.

These aren’t package prices. They’re the size of the conversation. The same “customer portal” can be a tidy login area or a core business platform with permissions, payments, audit history, reporting and integrations hanging off it.

Who does the work matters too. A principal architect who can shape the system, make the hard technical calls, build the first release and hand it over properly is not priced like a junior implementer, and shouldn’t be. Cheap early code has a habit of getting very expensive once you discover the foundations are wrong. The offshore-team version of this trap has its own economics, a low day rate multiplied by rework, communication overhead and a rescue phase, and we’ve covered it in the real risk of cheap outsourced development. The day rate is not the cost. The cost is what you’ve spent by the time the thing works.

Integrations add complexity

Connecting to Xero, CRMs, payment providers, booking tools, ERPs, mapping services or vendor systems can be where most of the value lives. It also hangs your project on external APIs, their data rules, their rate limits, their authentication and their habit of changing things on you.

So an integration-heavy build needs time budgeted for the failure cases. What happens when the API is down? When the customer already exists? When an invoice can’t be created? Those are the details that decide whether it survives in production. As a rough planning figure, each serious integration adds somewhere between a few thousand and $15,000 depending on the API’s quality and how much can go wrong at the boundary, and a build with four integrations is not four small line items. It’s a system whose behaviour depends on four external parties. Budget accordingly, and be suspicious of any quote that lists integrations without listing their failure handling.

The process may need work first

Sometimes the expensive part isn’t the code at all. It’s pinning down the business rules. When nobody can agree how approvals work, which data is the correct version, or which exceptions are allowed, the build ends up absorbing all that confusion and charging you for it.

You can hear this problem in the meeting before anyone writes code. Ask “what happens when a customer disputes an invoice?” and if three staff give three answers, the project has just grown, because someone has to resolve that before the software can encode it. Every unresolved rule becomes either a mid-build change order or a system that enforces a process nobody actually follows. A short scoping phase often pays for itself by surfacing the risky assumptions before development starts, which is exactly why it’s the first line in the budget list above and why we treat a written brief as the cheapest risk reduction on any project.

Maintenance is part of ownership

Software isn’t finished on launch day. Dependencies need updating. APIs change. Staff ask for improvements. Bugs turn up. Hosting and monitoring need looking after. Security patches keep coming.

A serious estimate covers the first build and the ongoing care, not just the build. A workable planning figure is 10 to 20% of the build cost per year for keeping the system healthy, patched, hosted, monitored and modestly improved. That’s not a penalty for choosing custom; it’s the same reality subscriptions hide inside the monthly fee. If you want to own the system, budget for the upkeep from day one, because software that nobody tends doesn’t stay still, it decays, and the decayed version costs far more to revive than the tending would have.

How to control cost

Start smaller. Build the workflow that creates value first. Reuse the tools you already have where they fit. Don’t pay to rebuild a feature a vendor product already does well. Spend the money on the parts that are yours alone.

The sequencing matters as much as the sizing. A $150,000 idea can almost always ship a $35,000 first release that handles the core workflow, proves the value with the people who’ll use it, and earns the next stage on results rather than faith. That path costs slightly more in total than building everything at once. It’s also dramatically less likely to produce the classic write-off, a big-bang system that arrives late, misses how the work actually happens, and gets routed around by staff within a quarter. For a lot of Australian businesses the smart path is a focused custom software release, then measured improvements once staff are actually using it. That keeps the first cheque tied to work people do, not to guesses.

The honest answer

Custom software is dear when you’re using it to replace a cheap subscription for a generic need. It’s good value when it takes away repeat work, protects a process the business runs on, ties systems together, or hands you control over something that matters.

Judge the cost against the process it fixes, the risk it removes, and the years you’ll run it. If you’re trying to put a number on a specific idea, send us the process it’s meant to fix, roughly who’d use it and what it has to connect to, and we’ll give you a real range instead of a guess, including a straight answer if the right response is a $50-a-month product and not us.