Which kind of app are we talking about?
"How much does an app cost?" is usually the first thing an owner asks us. Fair enough. But the word covers three different things, and the cost of each differs by several times, so the first job is working out which one you mean.
We've written before about how much a website costs and what a custom web application costs. This is the mobile version. It covers the three ways an app gets built, what each suits, roughly what it costs in Australia in 2026, and the ongoing bills that rarely make it into a first quote.
Every figure here is a rough guide. Cost follows scope, and scope is something we work out with you before quoting.
The three routes
A native app is written for one platform: Swift for iPhone, Kotlin for Android. Want both? You're building two apps that share a design and a backend. Native gives you the best performance, the deepest access to the phone's hardware and the most polished feel. It suits apps that lean on the camera, sensors, Bluetooth or heavy graphics, and apps where every millisecond matters, like games or trading tools. The catch is you pay for everything twice. Two codebases, two sets of bugs, two release cycles. For most of the businesses we talk to, native is the answer to a question they aren't asking.
Cross-platform frameworks such as React Native and Flutter let one team write one codebase that ships to both stores. You get a real installed app with push notifications, camera, location and most of what the phone offers. This is where most of the business apps we build sit. The saving over native is often close to half, and for ordinary functionality such as accounts, forms, bookings, dashboards and chat, a user can't tell the difference. Unusual hardware features sometimes need extra work to bridge, and you're one step removed from each platform's newest capabilities on launch day. Those are the trade-offs.
A progressive web app, or PWA, is a website built to behave like an app. It can sit on the home screen, work offline to a degree and send push notifications on most devices. No app store, no review process, no install step. Someone taps a link and they're in. It's by far the cheapest route, because one codebase also serves as your website. It suits customer portals, ordering, content-heavy apps and anything where the phone's hardware isn't central. It doesn't suit apps that need deep device access, background processing or an app store listing for credibility. We went into the offline side in our piece on offline-first PWAs.
Rough build costs in AUD
These are indicative ranges for the build only, based on what we see in Melbourne. Treat them as the start of a conversation.
- Simple app. A handful of screens, user accounts, a single core function such as booking, ordering, or viewing your account. As a PWA, roughly $25,000 to $50,000. Cross-platform, roughly $40,000 to $80,000. Native for both platforms, roughly $70,000 to $130,000.
- Mid-complexity app. Multiple user roles, integrations with your existing systems, payments, notifications, an admin dashboard. As a PWA, roughly $50,000 to $100,000. Cross-platform, roughly $80,000 to $180,000. Native for both, roughly $150,000 to $300,000.
- Complex app. Real-time features, offline sync, heavy device use, custom logic, high security or compliance requirements. These start around $180,000 cross-platform and go well past $300,000. Native versions sit higher again.
The gap between the low and high end of each band is wide because the answer moves a long way with scope. Pinning that down is what a discovery phase is for.
What pushes the price up
The features that sound small to an owner are often the ones that add weeks.
Offline sync is the big one. Letting the app work with no signal and then reconcile changes later is one of the harder problems in mobile. Site workers and field technicians need it, and it's expensive to do well. Payments add card processing, refunds, subscriptions and the rules Apple and Google impose on in-app purchases. Real-time features like live chat, live tracking or live availability need infrastructure behind them so two people can see the same thing at the same moment.
Integrations are a project inside the project. Your CRM, your accounting package, your job management tool, the old database that runs the warehouse. The older the system, the harder the work. Then there's the admin dashboard. The app your customers use is half the product; the web tool your staff use to run it is the other half, and it's the part that gets underestimated most. Every extra user type, whether customers, staff, admins or partners, means different screens, different permissions and different ways for things to go wrong.
The costs that don't make the quote
The build is the visible number. The ongoing costs are where owners get surprised, and they apply whichever route you pick.
Every app needs a backend: a server, a database and an API. That's true for native, cross-platform and PWA alike, so expect a monthly hosting bill that grows with users, plus the cost of maintaining the backend code. Apple charges an annual developer fee and Google a one-off registration fee, but the bigger cost is that every release goes through store review. Review can take days and can be rejected, and your developer bills for that time.
Apple and Google each ship a major operating system update every year, and each one can break something, deprecate something or require you to adopt something. An app that isn't maintained will stop working, usually at a bad moment. Android in particular runs on thousands of device and screen combinations, so testing takes time, and skipping it costs you reviews. Push notifications are cheap to send but not cheap to set up well, once you add segmentation, scheduling, deep links and analytics. And you'll want crash reporting and usage analytics from day one. The tools are often free at small scale, but wiring them in and reading them is not.
A reasonable rule of thumb is to budget 15 to 25 percent of the build cost per year to keep the app alive and healthy. We offer that through our support and maintenance retainers. An app without it is a slow-motion liability.
When a good website is enough
Most app agencies leave this section out, because it costs them work. But for a surprising share of people who come to us wanting an app, it's the right answer.
If your users need to find you, learn about you, book you or buy from you, a fast, well-designed mobile website almost always beats an app. Nobody wants to install something to look at a menu or check opening hours, and the install step alone loses most of your audience.
An app earns its keep when it does something a website can't: deep hardware access, meaningful offline use, a daily habit that benefits from a home screen icon, or a workflow your own staff use all day. If none of those describe your situation, spend the money on your website and put the difference into marketing.
We've talked plenty of people out of apps. We've also built apps for people who needed them, and those are the ones that get used. The technology is rarely the deciding factor. What matters is whether the app solves a problem someone has every day.
How we approach it
Our mobile app development work starts with that question. Before we pick a route, we look at who the users are, what they need to do, where they'll be doing it and what already exists in your business that the app needs to talk to. Then we recommend native, cross-platform or PWA on the merits and quote against a scope you've seen and agreed.
An app is never just an app. It's an app, a backend, an admin tool, a hosting setup and a maintenance plan. Having one Melbourne team build all of it means nothing falls into the gap between agencies.
If you're weighing up an app for your business and want a straight answer on which route fits and roughly what it will cost, get in touch.
