The cost of a business app comes down to seven factors: how many kinds of users the app has, how many other systems it must talk to, whether it takes payments, how sensitive the data is, how polished the design needs to be, who supplies the content, and who looks after it once it is live. Two apps that look alike on screen can differ on every one of them. No tool or shortcut removes the decisions, checks and conversations a working app needs, so the honest way to get a figure is a written scope and a written quote for your own project.
Why two apps that look alike get different quotes
From the outside, a booking app for a physio clinic and a booking app for a tour operator look like the same job. Underneath, one may have a single kind of user and no payments, while the other has customers, guides, an office manager, deposits, refunds and a link to an accounting package.
A developer prices the work underneath, not the screens you can see. That is why a quote based on "an app like that one" is a guess, and why a short list of what your app must do is worth more than a long description of how it should look.
business.gov.au gives the same advice for any digital tool: list your must-have and optional features before you start researching, and choose based on what you need, not what you might use later.
The factors that make a build bigger or smaller
Each row below is a question a developer will ask in a scoping conversation. The more rows that apply to you, the bigger the job.
| Cost factor | What makes the build bigger | What keeps it smaller |
|---|---|---|
| User types | Customers, staff and managers who each see and do different things | One kind of user, or a public page plus a single owner login |
| Integrations | Every other system the app must exchange data with: accounting, calendars, email, stock | Starting with an export or a manual step |
| Payments | Deposits, refunds, subscriptions, invoices that must match your books | Invoicing the way you do now, or one simple checkout |
| Data sensitivity | Personal information, or anything a stranger could misuse | Collecting only the details the app needs |
| Design polish | Custom illustration, animation, a visual style made from scratch | A clean layout built from proven components |
| Content | Words, photos and help text that somebody still has to write and check | Content you already have, organised and ready |
| Ongoing care | Security patches, backups, monitoring and new features after launch | A small, stable app, which still needs care, only less of it |
The first three rows add work in the same way: every extra kind of user or connected system needs its own screens, rules and tests.
Data sensitivity
An app that stores personal information needs access rules, careful storage and a plan for what happens if something goes wrong. The privacy regulator, the OAIC, tells start-ups to build the management of privacy risks into the design from the beginning rather than bolting it on later. It lists the need to redesign products, services and processes to retrofit privacy among the risks that can increase costs and cause delays.
The cheapest privacy measure is to collect less. The OAIC's guide to securing personal information says to collect only what is reasonably necessary for what you do, and notes that over-collection can increase security risks.
Design, content and ongoing care
Design polish is a choice, and one of the easier places to save. Content is the factor owners most often forget: an app with empty pages is not finished, and somebody has to write the words.
Ongoing care is part of the price whether or not it appears on the first quote. business.gov.au suggests working out the total cost of ownership of a digital tool, which it describes as the upfront cost plus the running costs over the tool's life span.
Where the time goes in a build
Some of the work in an app is predictable, and an experienced developer builds it from proven components instead of starting from nothing:
- Standard screens. The repetitive parts every app needs, such as forms, lists, sign-in screens and settings pages.
- A first working version. An early version of a screen that you can click through, so you can react to something you can see instead of a description.
- Tests. Automated checks that confirm a feature still works after the next change.
If most of your app is this kind of work, the build is smaller.
What does not get cheaper
The expensive parts of software were never the typing.
- Deciding. What the app should do when a customer cancels late, who may see what, which report the owner needs. Nobody knows your business rules until you say them.
- Reviewing and testing. Every feature has to be checked against the rules you agreed, on the phones and computers your staff and customers use, before anyone relies on it.
- Security. The Australian Signals Directorate says a business that develops software should use a quality assurance process that includes scanning the software for vulnerabilities. That is work on top of writing the features.
- Feedback rounds. Each demo produces changes. Seeing a working screen early can mean more rounds, not fewer, because you see more and so ask for more.
A quote that leaves these steps out is cheaper on paper and dearer later. To see where review and testing sit in a project, read how a Comingwave project runs, from the discovery call to ongoing support.
How to ask for a written scope and quote
You do not need technical language. You need to be specific about the job.
- Write down the goal. One or two sentences on what the app must achieve, such as fewer phone bookings or faster quoting.
- List the users. Name each kind of person who will use the app and the main things each one does.
- Split must-have from optional. Mark what the first version cannot launch without. Everything else goes on a later list.
- Name the systems and the data. Say which tools the app must connect to, whether it takes payments, and what personal information it will hold.
- Ask for the scope in writing. It should say what is included, what is left out, how changes are handled and what care after launch covers.
- Ask who owns the result. IP Australia says IP created by a contractor is the property of the contractor unless the contract states otherwise, and advises a written contract that defines who owns the IP, signed before work starts.
- Compare like with like. Give every developer the same list, then compare what each quote includes, not only the total.
Writing it down protects both sides. business.gov.au notes that business disputes can come from a misunderstanding or different expectations about the results of the work, and advises making sure everything you have agreed on is in the contract. The ACCC says any information a business provides about its services, including a quotation, must be accurate, truthful and based on reasonable grounds.
Comingwave is a technology company that provides these services to small and medium enterprises, and it gives a written fixed or staged quote that is agreed before work starts. The custom software and mobile apps pages describe what a build involves, and you can ask for a free first consultation to talk through your list.
Common mistakes
- Asking "how much for an app" with no list. Without the factors above, any figure is a guess, and guesses get revised.
- Treating every idea as a must-have. A first version that does a few things well costs less and teaches you more.
- Cutting review and testing to lower the price. Unreviewed code is a draft. Launching it moves the cost to the day something breaks.
- Leaving privacy and security for later. Retrofitting them is the dearer path.
- Agreeing on a handshake. If ownership, scope and the handling of changes are not written down, they are not agreed.
Frequently asked questions
Why do quotes for the same app differ so much?
Usually because each developer has assumed something different about what is included: the number of user types, the integrations, the testing, the security work and the care after launch. Give everyone the same written list and ask what each quote leaves out. A lower total often means a shorter list, not a cheaper way of doing the same work.
Why will a developer not give me a price over the phone?
Because the price depends on things a short call rarely covers: the number of user types, the systems to connect, payments and the data involved. A developer who quotes without asking about those is guessing. A written scope gives you something specific to hold the quote against.
Can I build a small first version and add to it later?
Yes, and it is often the sensible path. Launch with the must-have features, watch how people use them, then add from the optional list. A staged quote suits this, because each stage is scoped and priced before it starts. The custom software page covers this kind of build.
What should a written quote include?
At a minimum: what will be built, what is left out, how changes are priced, who owns the code, where it will be hosted and what care after launch covers. If a term is unclear, ask for it to be rewritten in plain words before you sign.
Key takeaways
- Cost follows the work underneath: user types, integrations, payments, data sensitivity, design polish, content and ongoing care.
- Standard screens are quick to build. Deciding, reviewing, security work and feedback rounds are where the time goes.
- Collecting less personal information and building privacy in from the start keeps the build smaller.
- Split must-have from optional features before you ask anyone for a price.
- Get the scope, the quote and the ownership of the code in writing before work starts.