The number you came here for
You searched a cost question, so here is a cost answer — the honest version, with the caveats attached rather than buried.
For custom operational software built in Australia, the ranges look roughly like this:
- A small internal tool or dashboard — one workflow, a handful of users, pulling data that already exists into something usable — typically lands somewhere around $25,000 to $60,000.
- A mid-sized operational system — a workflow tool, a custom LIMS-style data platform, a reporting system that several teams rely on, with a few integrations — usually falls between $60,000 and $180,000.
- A larger multi-workflow platform — several user types, real integrations with systems that don't share data cleanly, compliance or records requirements, data migrated off whatever runs the operation today — generally starts around $180,000 and goes up from there.
Those are real ranges for genuinely custom work. A focused, near-off-the-shelf tool with little that's truly bespoke about it can come in under $20,000 — but that's a different kind of product from what these numbers describe, and it's worth knowing which one you're actually buying. These ranges are also the least useful part of this article, and it's worth being clear about why.
Why that number is a starting point, not a price
A range is an average of projects that aren't yours.
Every one of the numbers above is the middle of a distribution. Two systems that look identical in a brief can differ threefold in cost, and the difference has almost nothing to do with the number of screens. It has to do with what's underneath — how clear the scope actually is, how tangled the existing data is, how many other systems this one has to talk to, and how well anyone understands the operation before the first line is written.
So the honest answer to "how much does custom software cost" is: enough of the answer to plan around, and not enough to sign against. If someone hands you a firm total before they've seen how your operation actually runs, the precision is manufactured. We'll come back to that.
What actually moves the number
If you want to understand your own likely cost better than a range can tell you, stop counting features and look at these six things. This is where the money genuinely goes.
Clarity of scope. The single biggest cost driver isn't complexity — it's ambiguity. A well-understood problem with clear edges is cheap to build relative to its size. A vague one is expensive at any size, because the cost of building the wrong thing and rebuilding it is baked in from the start, whether or not anyone names it.
Number of user types and workflows. One person doing one job is straightforward. The cost climbs with each distinct kind of user who needs a different view of the same system, and with each workflow that has its own rules, exceptions, and "except when" conditions. Operations are almost always more particular than they look from the outside.
Integrations. Connecting to a system with a clean, documented API is routine. Connecting to one that has no API, an undocumented one, or a database you're only allowed to read through a side door — that's where estimates quietly double. If your software has to exchange data with something that was never designed to share, that connection is often the most expensive part of the build.
The state of your existing data. Custom software usually replaces something — a spreadsheet, an ageing system, a process held together by one person's memory. Migrating that data means confronting how inconsistent it really is. Cleaning it, structuring it, and moving it without losing anything is frequently underestimated because it's invisible until you start.
Compliance and records. If your operation has to prove what happened — audit trails, regulated records, evidence that a step was taken by the right person at the right time — that requirement runs through the whole system, not a single feature. It's not expensive because it's hard; it's expensive because it touches everything.
How well the operation is understood before anyone builds. This is the one nobody puts on a cost driver list, and it's the one that decides whether the rest of the number holds. Software built to a brief costs what the quote says plus the cost of everything the brief missed — and briefs miss the workarounds, the informal steps, and the constraints nobody thought to mention. Software built to a genuine understanding of the operation costs what it costs, once.
The costs that never appear in the quote
The quote is for the build. The build is not the whole cost.
There's the cost of running and maintaining the system after it's live — hosting, updates, the small changes every real operation needs as it evolves. That's ongoing, and it's real, and it should be part of your thinking from the start rather than a surprise in year two.
Then there's the larger, quieter cost: the cost of the wrong build. A system delivered to a brief that didn't match the operation doesn't fail on day one. It works in the demo, the handover happens, the firm moves on — and then it starts not fitting. The team builds workarounds around it, the way they once built workarounds around the spreadsheet. That's the hidden cost of skipping the operating layer: you paid for a system and inherited a new version of the problem you were trying to solve. It's also how operational decay starts — a system that stops being trusted, one workaround at a time.
A cheaper quote that produces the wrong system is the most expensive option on the table. It just presents the bill later.
Why a fixed price before understanding is the least trustworthy number
Here's the uncomfortable part, and it's the reason we approach quotes the way we do.
When a firm gives you a firm total before spending real time in your operation, one of three things is true. Either there's so much hidden contingency in the number that you're paying for their uncertainty without being told. Or the quote is optimistic — priced to win the work, with the real cost set to emerge once you're committed. Or they've done this exact problem so many times they genuinely don't need to look — which is rarer than the confidence suggests.
None of those is a number you can plan a business around.
A quote that arrives before any real understanding isn't a price. It's a guess dressed up as a plan.
This is why we won't quote a project until we've paid attention to it first. Not as a principle for its own sake — because the alternative is quoting you a number we'd both have to pretend to believe.
How to budget for it sensibly
If a firm total isn't trustworthy up front, how do you plan?
You separate understanding from building. A short, fixed-fee piece of discovery — we call it a Discovery Sprint — buys you an honest read on your operation before any large commitment. We spend time with the people who actually run the system, map the workflow as it really works including the workarounds, and look at what already exists. Then we tell you what we found, including the parts that are uncomfortable to hear. If technology isn't the answer, you find that out for the price of a small investigation rather than the price of a build.
What comes out the other side is a real basis for a number: your operation properly on paper, the constraints made explicit, and a scope that's been tested against reality instead of assumed at a distance. That's when a figure you can actually plan against becomes possible — and it's the Understand → Build → Own shape all of our work follows.
If you're weighing a custom operational software build and want a grounded sense of what it would take, that's exactly what a Fit Call is for. Twenty-five minutes, no quote theatre.
A few questions we get asked alongside the cost one
How long does a custom software project take? Discovery is usually a few weeks. A first useful version of a mid-sized system typically lands in weeks to a few months, delivered in slices rather than as one big reveal at the end — because shipping in slices is how you catch a wrong turn while it's still cheap to correct.
Is custom always the right answer over off-the-shelf? No. Off-the-shelf genuinely wins when your process is standard and a product already fits it well. Custom earns its cost when your operation is particular enough that forcing it into someone else's product creates more friction than it removes. Discovery is partly there to tell you which situation you're actually in.
Are there ongoing costs after it's built? Yes — hosting, maintenance, and the small changes a living operation needs. Plan for it from the start. A system that's built to be owned by the people who depend on it is designed so those ongoing costs stay small and predictable rather than compounding.
One question worth asking
Before you accept any number for a custom software project, ask the firm one thing: what did you learn about our operation before you wrote this?
If the answer describes time spent with the people who run the work, the number has a foundation. If the answer is "we worked from your brief," you already know what the number is — a guess, and one you'll be the one to reconcile later.
