Custom Business Software in Australia: What It Costs and What Drives the Number
Published Australian estimates for a simple internal system start at around $15,000 and run to $60,000 or more before the first change request, priced off hourly rates that agencies rarely publish and that vary widely from firm to firm. That is not price gouging. It is what it costs to run discovery, design, build, test and project management the traditional way, on an hourly meter, with a team that has to be kept busy.
A small shop working with modern AI assisted development does the same work in far fewer hours, which means it can quote a fixed price rather than an estimate. The catch, and it is a real one, is that a fixed price is only honest when the scope is genuinely settled first. So we sell a paid blueprint before we sell a build, every time, without exception. This page explains what actually drives cost, how the blueprint gate works, and when you should not buy custom software at all.
Realistic ROI
What Actually Drives the Price of Custom Software
Four variables account for most of the difference between a modest system and one that costs ten times as much, and only one of them is the amount of code.
How well you can describe the process today
The single biggest cost driver is not technical, it is descriptive. A business that can walk through its own quoting or job process step by step, including the awkward exceptions, is cheap to build for. A business where three people each describe the process differently is expensive, because the difference gets discovered during the build and every discovery is a change. This is exactly what the blueprint exists to force out into the open while it is still cheap to change your mind.
The state of the data you want to carry across
Bringing ten years of jobs, customers and prices out of spreadsheets is often more work than building the screens that will replace them. Duplicate customers, three spellings of the same supplier, prices held in a column that is sometimes a number and sometimes text, dates entered as free text: all of that has to be resolved before it lands in a system that enforces rules. If your data is genuinely messy, buy the blueprint, then budget separately for the cleanup, and do not let anyone quote you a build price without looking at an actual export first.
How many other systems it has to talk to
A standalone system with no integrations is a comparatively simple thing. The cost climbs with every system it must exchange data with, and it climbs unevenly: a modern accounting package with a documented interface is straightforward, while an older on premise system that only exposes a database or a nightly file is a project of its own. Count the connections honestly at the start. Each one carries its own error handling, its own failure modes and its own ongoing maintenance, and each one is a place the estimate can quietly double.
How many different people have to use it
A tool for two people in the office is a different animal to a system used by twenty field staff on phones in bad reception with gloves on. The number of user types drives permissions, training, mobile behaviour, offline handling and the amount of testing required. Businesses routinely underestimate this because they scope the system around the office view of the process and forget that the person entering most of the data is standing in a customer’s driveway.
What a Fixed Price Build Actually Includes
Six components. The blueprint decides how much of each you need, which is why the blueprint comes first.
The blueprint
A paid deliverable in its own right, not a free sales document. We sit with the people who do the work, map the process as it actually runs including the exceptions, draw the screens, list the data, list the integrations, and write down what is explicitly out of scope. You get a document you could hand to any developer in the country. It is the only thing that makes a fixed price honest, and it is the mandatory gate before we quote a build.
The data model
How jobs relate to quotes, quotes to customers, customers to sites, sites to assets, and what happens when one of them is deleted or merged. This is the layer that decides whether the system still makes sense in three years or becomes the thing everyone works around. It is also where a spreadsheet migration either succeeds or turns into a manual retyping exercise, so we settle it during the blueprint rather than during the build.
The screens people use daily
The handful of screens that carry ninety percent of the work: raise a quote, book a job, record what happened, mark it complete, invoice it. These should be fast and unremarkable. Every extra field, tab and configuration option is a small daily tax on the people who use the system, and the most common failure in custom software is a build that captures more data than anyone will ever look at, entered by staff who quietly go back to the spreadsheet.
Connections to what you already run
Almost nobody needs the custom system to do accounting, and the ones who think they do usually change their mind when they see the price. The realistic pattern is a custom system for the part of the business that is genuinely yours, connected to the mainstream packages you already pay for. That means invoices flowing into the accounting system, notifications going out through the email you already use, and jobs appearing in the calendar staff already look at.
Reporting people will actually read
The point of getting off spreadsheets is usually that nobody can answer a simple question quickly: what is in the pipeline, which jobs are late, what did we make on that project. Two or three reports that answer the owner’s real questions beat a dashboard suite that impresses in a demo and is never opened again. We would rather build three reports well and add more later once you know what you keep asking for.
Handover, support and change
Written documentation, training for the people who use it, and a stated arrangement for what happens when something breaks or the business changes. Custom software is not a one time purchase, it is a small ongoing commitment, and any quote that pretends otherwise is hiding a cost. We will tell you what the ongoing hosting and support figure looks like before you commit, not after.
Where the Money Goes: Hourly Agency Versus Fixed Price After Blueprint
| Task | Traditional | Fixed price after blueprint | Notes |
|---|---|---|---|
| Discovery and scoping | Billed hourly, often weeks of workshops | A paid blueprint with a stated price and deliverable | Same work, bounded. You know what it costs and you own the document whether or not you proceed. |
| The estimate you receive | A range with contingency built in | One number for a defined scope | Contingency exists because scope is unknown. Settle the scope and the contingency stops being your problem. |
| Changing your mind mid build | A variation, quoted hourly, timeline slips | A written change with a price, agreed or declined | Changes are normal and should be priced, not punished. What matters is that both sides can see them coming. |
| Project management overhead | A billable line of its own, commonly around 10 percent or more | Included in the fixed number | On a small team the person managing the work is the person doing it, so it is not a separate cost centre. |
| Testing and rework | Billed as it happens | Our risk, not yours | This is the single biggest reason fixed price changes behaviour. Rework costs us, so we scope carefully. |
| Data migration from spreadsheets | Frequently excluded from the quote entirely | Scoped and priced from a real export | Ask any bidder to look at your actual data before quoting. If they will not, that cost is coming later. |
| Training and go live | Optional add on package | Part of the build | A system nobody has been shown how to use is not delivered, whatever the invoice says. |
| Ongoing hosting and support | Monthly retainer, often open ended | Stated figure before you commit | Small, but it is never zero. Any proposal that omits it is deferring a conversation you will have anyway. |
When Custom Software Is the Wrong Purchase
An off the shelf package already does eighty percent of it
If a mainstream job management, practice management or field service product covers most of what you need, buy it and adapt your process to the last twenty percent. Software subscriptions are cheap compared with building and maintaining your own, and the vendor absorbs security updates, compliance changes and platform shifts. Custom is the right answer when the way you work is genuinely unusual, when you have already tried a package and hit a real wall, or when the packages that fit are priced per user in a way that punishes a large field team.
Your data is a mess and you want to skip straight to the build
A custom system enforces rules that a spreadsheet never did, which means messy data does not migrate, it collides. Duplicate customers become duplicate records with different job histories. Prices held as text break calculations. If an honest look at your exports shows real problems, buy the blueprint, use it to plan the cleanup, and treat the migration as its own scoped piece of work. Building first and cleaning later is how projects go live and then quietly get abandoned in month three.
The process itself is broken and nobody has admitted it
Software makes an existing process faster and more consistent. It does not fix a process that is wrong. If quotes take nine days because they sit waiting for one person’s approval, a system will produce late quotes with better formatting. The blueprint stage is where this usually surfaces, and it is often the most valuable thing that comes out of it, because changing the approval rule costs nothing and building around it costs thousands.
Nobody internally will own it
Every successful internal system has one person inside the business who cares whether it is used properly, answers questions in the first month, and decides the small judgement calls that come up. Without that person, staff drift back to the spreadsheet within weeks and the system becomes an expensive read only archive. This is not a technical requirement and we cannot supply it. If you cannot name that person before the build, delay the build.
You are buying it to solve a people problem
Sometimes a system is proposed because two departments do not talk to each other, or because a manager wants visibility over someone they do not trust. Software will make that tension visible and permanent rather than resolving it. If the real driver is an unresolved argument about who decides what, sort that out first. A system built during an internal dispute tends to encode the dispute into its permissions and then nobody can change it.
The business is about to change shape
If you are mid acquisition, about to change your accounting system, restructuring the way jobs are allocated, or seriously considering a franchise model, wait. Every one of those changes the data model underneath a custom system, and rebuilding a foundation costs far more than building it once on the right shape. It is entirely reasonable to buy the blueprint now, hold it, and build in six months when the shape is settled. The blueprint does not go stale as fast as code does.
How Yes AI Sells and Builds Custom Software
The blueprint is a mandatory gate
We do not quote a build from a phone call, because a price given before the scope is understood is a guess dressed as a commitment. The blueprint is a paid deliverable: process mapped as it actually runs, screens drawn, data listed, integrations named, and an explicit out of scope section. You own the document and you are free to take it elsewhere.
One fixed price, with changes priced in writing
After the blueprint you get a single number for a defined scope, not a range with a contingency. Changes during the build are normal, and each one gets its own written price that you accept or decline. Nobody discovers the real cost at the end.
A small number of builds at a time
We take on two or three of these concurrently. Fixed price only works when the people who scoped the system are the people building it, and that limits volume. If we are full we will tell you and give you a date rather than start something we cannot finish properly.
We will tell you not to buy it
A good part of our scoping calls end with a recommendation to buy an off the shelf package instead, or to fix the process before building anything. That advice costs us the sale and it is still the right advice. If a product on the market covers most of what you need, we would rather point you at it than build you a slightly different version of it.
From First Call to a Working System
Five steps. The gate between step two and step three is the one that keeps the price honest.
Scoping call
A conversation about what the business does, what is currently held together by spreadsheets and email, what you have been quoted elsewhere, and whether an off the shelf package would serve you better. No charge, and we will say so plainly if the answer is that you should not build.
The paid blueprint
We map the process with the people who actually run it, draw the screens, define the data, list every integration and write down what is out of scope. Priced as a deliverable in its own right. It is yours regardless of who builds the system.
Fixed price quote
One number against the blueprint, with the change process, the hosting arrangement and the ongoing support figure stated up front. You have enough detail at this point to compare our number against anyone else’s on identical scope.
Build in visible increments
You see working screens early and often rather than a demo at the end. The people who will use the system get their hands on it while it can still be changed cheaply, which is where most of the useful feedback comes from.
Migrate, train, go live, support
Data brought across and reconciled against the old spreadsheets before switching, training for each user type, then a watched first fortnight. Documentation written, and a stated arrangement for changes after go live.
Related Reading
Internal Tools Development
When you need one process fixed, not a whole platform.
Replace Your Spreadsheets
The signs a spreadsheet has outgrown itself, and when it has not.
Replace Spreadsheets With Automation
The lighter option when the spreadsheet is fine but the copying is not.
How to Write a Project Brief
What to put in front of anyone you ask to quote.
Data Migration Services
Getting years of history out of spreadsheets and into a system.
SME Systems Integration
Connecting the custom part to the packages you already pay for.
FAQ
Get a Real Number Instead of a Range
Book a call. We will tell you whether an off the shelf package would serve you better, and if custom is genuinely the right answer, the blueprint gives you a document you can put in front of anyone.
All discussions held in confidence. Australian-based consultants.