Mobile app development cost: a practical scope guide

A mortgage calculator and a two-sided marketplace are both "mobile apps", and they share almost nothing in cost. The calculator has one kind of user, a handful of screens and no server. The marketplace has buyers, sellers and an admin, a database, payments that split between two parties, messaging and a moderation queue. Any single price quoted for "an app" is averaging those two together, which is why it rarely survives contact with a real brief.

Development cost is time multiplied by rate, and time follows a small number of measurable things. If you can describe these, you can compare quotes on equal terms:

• Screens and states: each distinct screen, plus its empty, loading and error states.
• Roles: every type of user (customer, staff, admin) needs its own flows and permissions.
• Backend: data kept only on the phone is far simpler than data on a server shared between users.
• Integrations: payments, calendars, CRMs and your own systems each need building, testing and error handling.
• Compliance: health, financial, children's or location data need extra safeguards and review.

The tiers below use those measures. They describe scope, not prices, because rates differ by team and region and we have not found a current, verifiable public survey of app prices worth quoting. Use them to place your idea, then ask for a written quote against that scope.

Tiers are easier to use once you have seen one scope written out. This is an example scope written in October 2026 for an account-based app. It is an example scope, not a customer project: a small facilities company wants its technicians to complete inspection checklists on their phones, add photos and a customer signature, and have the office receive a PDF report instead of retyping paper forms.

• Excluded: full offline use with sync conflict rules.
• Excluded: more than one checklist template type.
• Excluded: customer logins or a customer portal.
• Excluded: integration with accounting or job management software.
• Excluded: ongoing maintenance after the bug-fix window, which is scoped separately.

The smaller option: drop the office dashboard and send each report by email, or skip signatures, and the app moves toward the utility tier. If your checklists are standard and a generic PDF is acceptable, an existing inspection or forms app is often enough, and our guide on when to replace a spreadsheet with an app helps you check whether the time saved justifies a build.

Moving up one tier usually costs more than adding screens within a tier. Ten extra screens in a utility are mostly design and front-end work. A second role means permissions, a second set of flows, server rules about who sees what, and testing every combination.

Each app type has its own cost drivers. These guides go through them with a sample scope or worked example:

• Booking app development cost: availability rules, deposits, reminders and staff admin.
• Membership app development cost: member cards, gated content, renewals and store payment rules.
• Gym and creator membership app scope and cost: classes, workout content and challenges.
• Marketplace app development cost: two-sided roles, split payments, admin and moderation.
• Inventory app scope and cost: scanning, sync, permissions and reporting.
• Education app development cost: course companions versus school systems.
• Custom calculator app development cost: pricing rules, data and what happens to the result.
• Loyalty app scope and cost: earning, redemption limits and the POS boundary.
• Utility app scope and cost: workflows, sync and phone permissions.

An MVP is the smallest version of the app that tests whether people will use it for the job you have in mind. Its cost drops when you hold the tier down, so the useful MVP question is which role, flow and integration you cannot launch without.

• Keep the one flow your main user repeats, polished properly, plus sign-in and account deletion if you have accounts at all.
• Keep the single integration the business cannot run without, usually payments or a calendar.
• Replace a custom admin dashboard with your payment provider's dashboard or a shared spreadsheet for the first months.
• Replace in-app chat with email or SMS links until you know people want to talk inside the app.
• Launch with one sign-in method instead of four.
• Add analytics events for the flow you are testing, so the MVP produces an answer.

If a standard booking or membership product already covers your flow, buying it is often the better MVP. Our build vs buy comparison for booking apps walks through when a subscription tool is enough.

The build is a one-time cost. These keep coming, and most are paid directly by you to the provider, in accounts held in your name:

Maintenance is the line people forget. Apple and Google raise their technical requirements every year, and an app that is never updated eventually stops being accepted for updates. The guide to maintenance after delivery lists what comes up and who is responsible.

Our custom app builds are quote-only. The work runs through discovery, a clickable prototype, the build, integrations, QA and store submission, and the written scope you receive lists the screens, roles, integrations, assumptions, timeline and price before anything starts. Developer, hosting and payment accounts stay in your name.

The fastest route to an accurate number is a clear brief. The app brief template has worksheets for screens, roles and integrations, and the quote form asks the same questions in about four minutes.