Mobile app development cost depends on what the app has to do. Every feature, whether it's a login, a booking calendar or offline sync, has to be designed, built and tested, and the effort behind each one varies a lot. The part you see is usually small; handling everything that can go wrong around it is where most of the work goes, along with testing on real iPhones and Android phones.
Below we look at what drives that effort, which features most business apps have and what only a phone app can do. Then we break three sample apps down feature by feature, each with an approximate team and a typical cost range. After that come the costs nobody can negotiate (the store fees and the yearly updates Apple and Google require) and the cases where a web app would do the job for less.
Why are app quotes so far apart?
Because two quotes for "an app" are rarely pricing the same thing. One might be a single platform with a sign-up and a booking form, and the other iPhone and Android with payments, an admin panel for your staff and a connection to your customer relationship management (CRM) system. The rate behind each can differ a lot too, depending on where the team is.
Most cost guides answer with "simple, medium, complex" tiers but never say what's inside each one, so you can't tell where your idea fits. Our sample apps below come with their feature lists instead.
Features, effort and testing: what really drives the cost
Most of an app's effort sits around each feature rather than in it. A feature that looks like one line on a wish list usually hides a lot more, and the testing that proves it works on real phones comes on top of that.
Take "customers can book an appointment". The main flow is simple enough: pick a service, pick a time, confirm. However, the app also has to show only the times that are really free, stop two people taking the same slot, handle changes and cancellations, send a reminder, and cope with a phone that loses signal halfway through. Each of those gets designed, built and tested, and together they're most of the work.
So when we estimate, we go feature by feature and ask three things: what it has to handle, what it connects to, and what happens when something goes wrong. Two apps with the same number of features can end up far apart, because one has payments with refunds and the other has a contact form.
The part that most often grows past what anyone planned isn't a feature, though. It's the database design. Almost every feature reads from it or writes to it, so a bit of extra scope on one feature often means reworking how the data is stored as well, and since nobody sees that on a screen, it rarely comes up until it has to change.
Most business apps also need a backend: a server, a database and an admin panel where your team manages users, bookings or orders. Clients don't often picture this part when they describe the idea, but it's in every sample below and takes a good share of each. Every outside system the app talks to through an application programming interface (API), like a payment processor, a point-of-sale (POS) system or a CRM, is its own piece of work. API integrations are where real data from someone else's system meets yours, and they tend to take longer than people expect.
Then there's testing, which takes a bigger share on a phone than on a website. An app has to work on iPhones and Android phones of different sizes and ages, on the last few versions of each operating system, when the user says no to a permission, on a weak signal, and after it's been sitting in the background for an hour. A simulator on a developer's laptop catches some of that; the rest only shows up on real devices. Testing gets its own line in every sample below, and it's the last place we'd cut.
Features most business apps have
Most business apps are built from the same set of parts, so this list is a good place to start your own:
- Sign-up and login, often with Apple or Google sign-in
- A profile and account settings
- A home screen or feed with what's new for that user
- Lists with search and filters, for products, services or listings
- A detail page for each item
- Forms for bookings, orders, requests or uploads
- Payments, saved cards, receipts and refunds
- Messaging or chat with your staff
- Notifications, both inside the app and as push notifications
- An admin panel for your team
- Analytics, so you can see what people actually use
Each one gets designed before it's built: the user experience (UX), meaning how people move through it, and the user interface (UI), meaning how it looks. None of these is unique to a phone, though, and a web app can have nearly all of them. What sets a mobile app apart is what it can do with the phone itself.
What a mobile app can do that a website can't
These features either only work in an app installed on the phone, or work much better there. They're often the whole reason to build one, and each adds its own effort, mostly in permissions, edge cases and testing.
| Feature | What it does for your business | What it adds to the build |
|---|---|---|
| Push notifications | Reminders, order updates and offers that reach people on the lock screen | A notification service, settings for what each user receives, testing on both platforms |
| GPS and background location | Store finders, delivery tracking, a check-in when a technician arrives on site | Permission prompts that explain why, and care for the battery |
| Camera and photos | A photo of a finished job, a scanned barcode or document, a profile picture | Image handling and uploads, plus storage on the backend |
| Biometric login (Face ID, fingerprint) | Signing back in with a glance or a touch instead of a password | Secure storage on the device, and a fallback when it doesn't work |
| Offline mode and sync | Working in a basement or on a rural job site, then catching up when the signal returns | Local storage and rules for when two people changed the same record; usually one of the heaviest features |
| Bluetooth and NFC | Talking to a card reader, a scanner, a wearable or a smart lock | Testing with the actual hardware, often device by device |
| In-app purchases and subscriptions | Selling digital content or memberships inside the app | Each store's billing set up separately, and the store's commission (below) |
A browser can reach a couple of these in a limited way, like taking a quick photo. However, it can't track location in the background, keep working offline or talk to most hardware, and that's usually where the case for a store app gets made.
Three sample apps, and what each one costs
Here's how the work splits across three typical business apps. Each one is a single cross-platform app for iPhone and Android (more on that choice below) with a backend and an admin panel. The percentages are each part's share of the total build, and the ranges are what an app like it typically costs with a US team. They're a guide for comparing, not a quote for your app.
A focused app: appointments for a local service business
A clinic, a salon or a repair shop that wants clients to book and get reminders without phoning. There's one type of user, no payments in the app, and a simple admin panel for the front desk.
Team: roughly two developers and a part-time project manager.
| Part of the build | Share of the work |
|---|---|
| UX and UI design | 14% |
| Sign-up, login and profile | 10% |
| Services list and booking calendar | 20% |
| Push reminders | 7% |
| Backend, database and admin panel | 20% |
| Testing on real devices | 15% |
| Store submission and launch | 4% |
| Project management | 10% |
Typical cost: about $30,000 to $45,000. The booking calendar and the backend behind it are the two biggest parts of the build, which is normal for this kind of app. That's where the free times, double bookings and cancellations actually get handled.
A mid-sized app: ordering and loyalty for a multi-location business
A restaurant group or a retailer with a few locations, whose customers order ahead, pay in the app, collect points and find the nearest store. The app connects to the POS system and the CRM, and sends updates as an order moves along.
Team: roughly three developers and a part-time project manager.
| Part of the build | Share of the work |
|---|---|
| UX and UI design | 11% |
| Accounts, login, Face ID or fingerprint sign-in | 7% |
| Menu or catalog with search | 9% |
| Cart, checkout and payments | 14% |
| Loyalty points and rewards | 7% |
| Store locator with maps | 5% |
| Push notifications for orders and offers | 5% |
| POS and CRM integration | 10% |
| Backend, database and admin panel | 12% |
| Testing on real devices | 10% |
| Store submission and launch | 2% |
| Project management | 8% |
Typical cost: about $80,000 to $120,000. Payments and the POS connection take about a quarter of the budget between them. They're where real money and another company's system are involved, so most of the edge cases live there: a declined card, a refund, an item that sold out between the menu and the checkout.
A high-effort app: field service that works offline
A company with technicians on the road. They get their jobs on the phone, find their way to each one, take photos and a customer's signature, and close the job even where there's no signal. The office plans and tracks the work from a web dashboard, and finished jobs flow into the accounting system as invoices.
Team: roughly four people on design and development, plus a full-time project manager.
| Part of the build | Share of the work |
|---|---|
| UX and UI design, for the app and the dashboard | 8% |
| Roles, login and permissions | 5% |
| Work orders and scheduling | 9% |
| Offline mode and sync | 11% |
| GPS tracking and routes | 6% |
| Photos, signatures and documents | 5% |
| Chat between office and field | 4% |
| Dispatch dashboard for the office (web) | 8% |
| Accounting integration and invoicing | 7% |
| Backend and database | 8% |
| Testing on real devices and in poor signal | 9% |
| Store submission and launch | 2% |
| Project management | 18% |
Typical cost: about $170,000 to $270,000, and more as features are added. Offline sync is the biggest single feature here. The app has to keep working on its own for hours, then merge its changes with everyone else's when the signal comes back, without losing a job or a signature. Project management takes a bigger share than in the smaller apps too, since a team of five needs someone coordinating it full time.
If your idea sits between two of these, it'll likely cost somewhere between them. Start from the closest sample and swap features in and out; the shares show roughly what each swap is worth.
iOS, Android or both? Native or cross-platform?
For most small and mid-sized businesses we recommend one cross-platform app that runs on both iPhone and Android, and we usually build it in React Native. Your customers won't all carry the same phone, and with a single codebase every feature and every later fix gets done once instead of twice. Flutter is another framework that works the same way.
We'd build native apps (Swift for iOS, Kotlin for Android) instead in two cases. One is an app that leans hard on device-specific features, where each platform's own tools do the job better. The other, and the stronger case, is when you really only need one platform, like an app for your own staff who all carry company iPhones. With a single platform there's little for cross-platform to save, so native makes more sense.
If most of your customers are on one platform, you can also launch there first and add the other later. With React Native, the second platform is mostly testing and store work rather than a second build.
The fixed costs of being in the App Store and Google Play
These are small and they're the same for everyone, as of November 2026. Apple charges $99 a year for its developer program, and Google charges $25 once. If you sell through the stores, both take a commission. Google takes 15% of your first $1 million a year, and Apple takes 15% if you made up to $1 million the year before (or are new to the store) and enroll in its Small Business Program.
| Cost | Apple App Store | Google Play |
|---|---|---|
| Developer account | $99 a year | $25 once |
| Commission (store service fee) | 15% on paid apps and in-app purchases if you enroll in the Small Business Program and earned up to $1 million the year before | 15% on the first $1 million a year, 30% above that |
A couple of details people miss. As we read Apple's terms, the commission is on paid apps and in-app purchases, so a free app with nothing sold inside it doesn't pay it.
So is Android app development free? Not really. The Google Play account is a one-time $25, but the developer's time is what you're really paying for, same as on iPhone.
There's also a small practical step that can hold up a launch. To publish under your company's name, Apple needs a D-U-N-S Number to verify your business as a legal entity. It's free in most places, but it's one more thing to sort out before you can submit, so it's worth requesting while the app is still being built.
What an app costs every year after launch
Plan on two kinds of running costs: services, like the backend's hosting, which are usually modest, and maintenance time, which you can't skip. Apple and Google both tie their requirements to recent versions of iOS and Android, and an app that falls behind can't ship updates, or stops reaching new users.
Here's what that looks like in 2026. Apple now requires every app uploaded to App Store Connect to be built with Xcode 26 and the iOS 26 software development kit (SDK), the set of tools an app is built against. In practice, as we read it, an app that hasn't been brought up to date can't go out with even a small bug fix until it is. On the Android side, Google Play has required new apps and app updates to target Android 16 since August 31 (developers could ask for an extension to November 1, which has now passed). Apps that fall behind that target also become unavailable to new users on newer Android phones.
Since both requirements are tied to current versions of iOS and Android, we'd expect them to move again as new versions come out. So we think of maintenance and updates as the cost of staying in the stores, not an optional extra. On top of that come bug fixes and library upgrades, plus the small changes your users will ask for once they're using it.
The backend has its own bill. As one example, Supabase, which many apps use for the database and logins, starts its Pro plan at $25 a month, which includes 100,000 monthly active users and $10 of compute credit. Its free projects pause after a week without activity, so a live app needs a paid plan. Other backends price differently, and push notifications or email sending often add a line of their own.
Someone has to own all of this after launch. Our hosting and maintenance packages cover this kind of work, so a developer is on hand when you need one, and we look after the hosting and keep the app's architecture current. Whoever does it for you, put the hours in the budget from the start.
When a web app is the less expensive answer
For most businesses that ask us for an app, a web app is the better first choice. It runs in the browser on any phone or computer, so there are no store fees or reviews and no yearly platform deadlines, and an update is live as soon as it's published. It usually costs less to build as well, since there's no store submission, less device testing, and the admin panel and the customer side can often be one app.
Apple also has a say here. Its App Review Guidelines ask for features, content and UI that take an app beyond a repackaged website, and an app that's basically a website in a wrapper may be rejected. So if your app idea would mostly show what your site already shows, the store may not take it anyway.
We'd recommend a store app when there's a real reason for one:
- It has to work offline, like a technician's app in a basement or out on a rural site.
- It uses the phone's hardware beyond a quick photo: background location, Bluetooth or NFC, or biometric sign-in.
- People use it often, daily or weekly, and expect it on their home screen with push notifications.
- The stores are where your customers look. If people expect to find you in the App Store or Google Play, being there is part of the product.
If none of those apply, a web app will likely do the job for less. Our web applications page shows the kind we build, and the web app cost post covers what goes into one.
How long does it take to build an app?
With the teams in the samples above, a focused app like the appointment one typically takes about five to eight weeks from kickoff to the stores, a mid-sized app like the ordering one two to three months, and a high-effort app like the field service one three to five months. Those are typical ranges. Your feature list decides where in them you land, and a smaller team takes longer.
What stretches a timeline most is usually on the decision side, not the code: extra rounds of design changes and slow approvals, plus features added halfway through. Integrations can add waiting too, since you depend on another company for API access and answers. Store review comes at the very end, where a rejection sends the app back for changes, so we'd leave some room before any launch date you announce.
Hiring an app developer in Los Angeles
A local team costs more per hour than an offshore one, and what you get for it is mostly easier communication and fewer surprises. We think that's worth a lot on an app, where many decisions come up halfway through the build, though it only makes sense to compare the two on the same scope.
A local team offers a few things worth weighing against the rate:
- Same time zone. A morning question gets a same-morning answer, and over a months-long build those saved days add up.
- Meeting in person. Sitting down with the designs on a table can settle a question faster than a video call.
- Contracts and ownership. A US contract that assigns you the code and designs is simpler to write and to enforce.
- US rules. A team that already builds to US privacy expectations and the Web Content Accessibility Guidelines (WCAG) won't need them explained.
As for the hourly rate, US wage data sets a floor. Software developers earned a median of $135,980 a year in May 2025, according to federal wage data, and that's an employee's pay before benefits, tools and management. A development agency's rate sits well above it, so a US quote that seems to undercut it is worth a closer look.
Whoever you hire, in Los Angeles or anywhere else, hand every agency or software company the same feature list and ask each one to show its estimate feature by feature. A low total with no breakdown is pretty hard to judge, because you can't see what was left out to get there. We're based in Los Angeles and work with businesses across the US. If the app quotes you've got don't line up and you'd like a second opinion, we'll look them over with you through our consulting service.
Before you ask for an estimate
Start with the goal: what the app has to change for your business, whether that's more bookings, fewer phone calls or a tool your field staff can't work without. Then write down the features, using the lists above: which of the common ones you need, which phone features, what systems the app has to connect to, and which platforms. Mark what has to be there at launch and what can wait.
A first version, or minimum viable product (MVP), should do its main job properly for real users. We like to plan the whole product first and then trim it to the core, rather than guess at a small app and bolt things on later, but whatever ships first still has to work. Set aside time and money for the updates after launch from the start, since that's the part of the budget that's easiest to forget.
We design and build mobile apps for iPhone and Android, and we'll tell you when a web app would do the job for less. If you have an app in mind, send us your feature list, even a rough one, and we'll come back with an estimate broken down the same way.
