What a business app costs in Australia depends on a short list of drivers: how many kinds of user it serves, how many screens and workflows it has, what it connects to, whether it takes payments, how sensitive its data is, which platforms it runs on, and who looks after it once it is live. No honest figure can be given before those are known. This guide explains each driver, the two common ways a quote is structured, and what a written quote should contain so you can compare offers on the same footing.
Why there is no standard price for a business app
Two apps that look alike on a phone can be very different underneath. A booking app for one clinic's front desk, with a single staff login and a calendar, is a small piece of software. A booking app for a group of clinics, with patient accounts, practitioner rosters, card payments, reminders and a link to the accounting package, is several systems working together.
The screens a customer sees are only part of the work. Most of the effort sits behind them: the database, the business rules, the admin tools, the integrations and the testing. A useful quote comes after a discovery conversation in which the scope is written down.
The cost drivers, one by one
User roles and screens
Each type of user (customer, staff member, manager, administrator, supplier) needs its own screens, permissions and test cases. A builder's job-tracking app used only by site supervisors is far smaller than one that also gives clients a progress view and lets subcontractors upload invoices. Count the roles first, then list what each role must be able to do.
Integrations
Connecting the app to other systems, such as Xero or MYOB, a CRM, a stock system or an email service, is done through an API (a documented way for two programs to exchange data). Each integration has to be built, tested against realistic data and watched afterwards, because the other system will change over time. An integration that only reads data is simpler than one that writes back and has to handle errors and duplicates.
Payments
Taking card payments, deposits, subscriptions or refunds adds work in three places: the connection to the payment provider, the bookkeeping that follows each transaction, and the handling of failed or disputed payments.
Data sensitivity and security
An app that holds names and email addresses needs sound basic security. An app that holds health details, identity documents or financial records needs more: tighter access control, encryption, audit logs, and a plan for what happens if something goes wrong. Australian Privacy Principle 11, as summarised in the OAIC's quick reference to the Australian Privacy Principles, says an organisation covered by the Privacy Act must take reasonable steps to protect the personal information it holds from misuse, interference and loss. The more sensitive the data, the more design and testing those steps take.
Platforms
An app can run in a web browser, on iPhone, on Android, or on all three. A web app reaches every device with one build. Phone apps add store accounts and store submissions. A cross-platform framework such as Flutter lets one codebase serve both phone platforms, which usually means less to build and maintain than two separate native apps.
Store accounts deserve a line of their own. Apple says you can enrol in the Apple Developer Program as an individual or enrol your organisation, and that an organisation must be a legal entity enrolled by someone with authority to bind it. Google says Google Play offers two developer account types, Personal and Organization. For a business app, open the accounts in your business's name, not your developer's, so the store listing stays with you.
Design
Design effort ranges from a clean layout built from the platform's standard components to a fully custom look with illustration and animation. Staff-facing tools rarely need the second.
Content and data migration
If the app replaces spreadsheets or an older system, the existing records have to be cleaned, mapped and moved. A wholesaler with years of customer and price history in several formats should expect migration to appear as its own line in the quote.
Hosting and ongoing support
An app is not finished at launch. It needs hosting, monitoring, backups, security updates, and changes when phone operating systems or connected services change. These costs recur for as long as the app is in use. A quote that covers only the build tells you half the story.
Cost drivers at a glance
| Driver | Lower effort | Higher effort |
|---|---|---|
| User roles | One role, such as staff only | Customers, staff, managers and suppliers, each with different permissions |
| Integrations | None, or one read-only connection | Two-way links to accounting, CRM and stock systems |
| Payments | No payments in the app | Cards, deposits, subscriptions and refunds |
| Data sensitivity | Basic contact details | Health, identity or financial records |
| Platforms | Web app only | Web, iPhone and Android |
| Migration | Starting with no existing data | Years of records in mixed formats |
Fixed quote versus staged pricing
A fixed quote is one price for a defined scope. It suits projects where the requirements are clear and unlikely to move. The scope document carries the weight: anything outside it becomes a variation with its own price, so read it as carefully as the total.
Staged pricing divides the project into stages, such as discovery, a first release and later releases, with each stage quoted and agreed before it starts. It suits projects where you expect to learn as you go, because you can change direction or stop between stages without having committed to the whole.
Either way, the price and the scope should be in writing and agreed before work starts.
What a good written quote contains
- A plain-language scope: the user roles, the main screens and what each one does.
- A list of what is excluded, so there are no surprises.
- Each integration named, with the direction data flows.
- The platforms covered and the technology proposed.
- How testing is done and who signs off each stage.
- Data migration: what is moved, by whom, and in what condition it must arrive.
- Hosting and ongoing support costs, shown separately from the build.
- How changes to scope are priced.
- Payment milestones tied to things you can see working.
- Who owns the code, the data, the documentation and the store accounts.
The last point is easy to miss. The Australian Government's guidance on hiring contractors on business.gov.au says that if you want your business to own the intellectual property, the contract must clearly say so. Otherwise the contractor will own the IP in the work they create during the contract period.
How to reduce cost sensibly
- Start with the smallest version that does one job properly. Add the rest once people are using it.
- Consider a web app first. If staff only need it at a desk or in a browser on site, the app stores may not be needed yet.
- Use standard components. Standard sign-in, payment and email services are cheaper to adopt than to rebuild.
- Clean your data before migration. Removing duplicates and dead records yourself shortens the work.
Do not save money by cutting security, testing, backups or documentation. Those are expensive to add later.
Where Comingwave fits
Comingwave is an Australian technology company that provides technology and business solutions to small and medium enterprises. We build mobile apps and custom software, and our IT consulting service can help you scope a project before you ask anyone to price it. The first consultation is free, quotes are written and either fixed or staged, and clients own their code, data and documentation. To talk through your app, request a quote.
Key takeaways
- The cost of a business app is set by its roles, screens, integrations, payments, data sensitivity, platforms, design, migration and support.
- Any price given before the scope is written down is a guess.
- Fixed quotes suit stable scope. Staged pricing suits projects that will evolve.
- A written quote should show exclusions, ongoing costs and ownership as clearly as the total.
- Reduce scope to reduce cost. Do not reduce security or testing.
Frequently asked questions
Why can't a developer give me an app price over the phone?
Because the price depends on details a short call rarely covers: the number of user roles, the integrations, whether payments are involved and how sensitive the data is. A figure given before those are written down is likely to change once they are.
Is a fixed quote safer than staged pricing?
A fixed quote gives certainty on price only for the scope it describes. If your requirements are likely to change, staged pricing can be the safer choice, because each stage is agreed on its own and you can adjust between stages.
Do I need both an iPhone and an Android app?
Not always. If your users are staff, a web app or a single cross-platform build may cover everyone. If your customers will install the app, check which phones they use before paying for more than one platform.
Who should own the code and the app store accounts?
Your business should. Make sure the contract states that you own the intellectual property, and open the Apple and Google developer accounts in your business's name so the listings stay under your control.
What ongoing costs should I plan for after launch?
Plan for hosting, monitoring, backups, security updates, and changes needed when phone operating systems or connected services change. Ask for these to be shown separately in the quote.