If you're thinking about custom software, the first question is usually what it will cost. It's a fair question, and it's also the one that gets the vaguest answers.
That's partly because "custom software" covers everything from a small internal tool to a full commercial product. Two projects with similar descriptions can need very different amounts of work. This article explains what actually drives the cost, so you can judge estimates with more confidence and scope a project that fits your budget.
Our starting point
Custom software and automation projects typically start from A$2,500. Final pricing depends on the systems involved, complexity and scope.
We don't publish price tables, and we're wary of generic "industry average" figures, because they rarely match the project in front of you. For anything beyond a small, clearly defined tool, the right next step is an initial consultation so the scope can be properly understood.
Three very different kinds of project
A small internal tool
This might be a form and dashboard that replaces a fragile spreadsheet, an approval screen, or a simple tool that pulls information from one system and presents it to a team. It has a small number of users, a clear purpose and few integrations. These are usually the most predictable projects to scope.
A larger business platform
This is software that runs a core part of the business: job management built around your process, a client portal, or a system that brings several tools into one operational view. It typically has several user roles, more business rules, more integrations and more data to migrate. Scoping matters much more here.
A SaaS product
Building software to sell to other businesses is a different category again. On top of the features, it needs things like account sign-up, billing, multi-customer data separation, onboarding and support processes, and a plan for ongoing development. It's closer to building a business than building a tool.
Knowing which of these you're actually describing is the first step to a realistic estimate.
The main cost drivers
Scope
The number of features, screens and workflows is the most obvious driver. Every feature needs designing, building and testing. The most effective way to control cost is to be clear about what the first version genuinely needs.
User roles and permissions
A tool used by one team with the same access is simpler than one with administrators, staff, managers, customers and contractors who each see different information. Every role adds permission rules that need to be built and tested.
Integrations
Connecting to your existing systems is often where the real complexity sits. A system with a well-documented API is very different from one that only offers spreadsheet exports. Each integration also needs error handling for when the other system is unavailable or returns unexpected data. Our system integrations work and our article on what to do when your business software doesn't integrate go into the options.
Design complexity
A clean, functional internal interface takes less work than a highly polished, customer-facing experience with custom branding, animations and detailed responsive layouts. Both have their place. The question is what the users actually need.
Data migration
If information is moving from spreadsheets or an old system, someone needs to map it, clean it and check it. Duplicate records, inconsistent formats and missing fields all take time to resolve. Moving messy data into a new system doesn't make it clean. We cover this in how to replace spreadsheet-based business processes.
Security and privacy
Any software that handles customer or staff information needs proper access controls, secure hosting and sensible handling of personal data. If your business is covered by the Privacy Act, the OAIC's guidance on APP 11 explains that you must take reasonable steps to protect personal information, and that what's reasonable depends on factors such as the amount and sensitivity of the information held. More sensitive data means more security work, and that work should be scoped, not bolted on later.
Mobile requirements
A web application that works well on a phone's browser is usually simpler than a native app. Publishing to the Apple App Store requires an Apple Developer Program membership and passing Apple's App Review, and Google Play requires a Play Console developer account. Supporting both platforms, offline use or device features like the camera and location adds more again.
Support after launch
Software isn't finished when it goes live. It needs hosting, monitoring, security updates and changes as your business and connected systems evolve. That's ongoing cost, and it should be discussed before the build starts.
Discovery and scoping
For anything beyond a small tool, a discovery or scoping stage is worth it. That's where the workflow, users, integrations, data and priorities are mapped before development starts. Some providers treat this as a separate, paid stage and others include it in the build, so ask how it's handled.
Either way, the output should be a clear picture of what will be built first, what's deliberately left for later, and what assumptions the estimate relies on.
Why vague fixed-price estimates can be risky
A fixed price sounds safe. But a fixed price based on a one-paragraph description has to absorb a lot of unknowns. That usually goes one of a few ways:
- the price is padded heavily to cover risk, so you pay for uncertainty
- the scope is interpreted narrowly, and anything not written down becomes a variation
- corners are cut on testing, error handling or documentation to stay within budget
None of those are good outcomes. A fixed price is far more reliable when it's based on a properly defined scope. If an estimate arrives quickly with very little detail, ask what's included, what's excluded and what happens when requirements change.
How to reduce cost with phased delivery
The most reliable way to keep custom software affordable is to build it in stages.
The Australian Government's Digital Experience Toolkit describes a minimum viable product as the simplest thing you can build that meets the user need. The same idea works for business software:
- start with the workflow that causes the most pain
- build the smallest version that solves it properly
- put it in front of real users and learn from how they use it
- add features based on evidence, not assumptions
Phasing spreads the cost, reduces the risk of building the wrong thing and gets value into the business sooner. It also makes later stages easier to estimate, because you're building on something real.
Sometimes the first phase isn't new software at all. It might be connecting the tools you already have and building only the missing layer.
Ongoing support and hosting
When comparing quotes, ask about the costs after launch:
- where the software will be hosted and who manages it
- how security updates and dependency upgrades are handled
- what happens when a connected system changes its API
- how bugs, changes and new features are requested and priced
- who owns the code, the hosting accounts and the data
Our ongoing support service exists for exactly this, so a system that matters to your daily operations keeps working after the build is done.
When custom software isn't worth the cost
Custom software is the wrong investment when an existing product already does the job well, when the process is still changing week to week, or when the problem is really an unclear process rather than missing software. In those cases, configuring what you have, adding an integration or simplifying the process will usually deliver more for less. Our guide on whether to automate a process or replace the software can help you work out which one you're facing.
Frequently asked questions
How much does custom software start from with 23Labs?
Custom software and automation projects typically start from A$2,500. Final pricing depends on the systems involved, complexity and scope. Larger projects are scoped through an initial consultation.
Why can't you give an exact price straight away?
Because the cost depends on details like integrations, user roles, data and security that usually aren't clear from a short description. A quick price without that detail is a guess, and guesses tend to cost more later.
Is a web app cheaper than a mobile app?
Usually, because a single web application can work across devices, while native apps involve separate platform requirements and app store processes. The right choice depends on how and where your users need to use it.
How does custom software cost compare with automation?
Automation that connects existing tools is often smaller in scope than building new software, because there's no new interface to design. See how much business automation costs in Australia for the drivers on that side.
Talk through your project
If you have a project in mind, the most useful first step is a conversation about the workflow, the users and the systems involved. From there we can tell you whether it's a small tool, a larger platform or something better solved another way. Learn more about our custom software development work, or start a conversation when you're ready. There's no obligation.