How much does it cost to build an app in 2026? A scoping guide

How much does it cost to build an app in 2026? It depends on scope, platforms, integrations and risk, not on the idea itself. Illustrative ranges run from a few thousand dollars for a validated prototype to six figures for a cross-platform product with payments and AI. Treat every figure as an assumption-based estimate, never a quote.

Why app cost estimates vary so widely

Two apps described in one sentence can differ enormously in effort. 'An app like a booking marketplace' hides the number of user roles, the admin tools, offline behavior, payment flows, notifications, integrations and compliance needs. Until those are written down, any number is a guess.

Vendors also price different things. Some estimates cover only development. Others include product design, quality assurance, deployment, app store submission and a support period. Comparing them without normalizing scope is comparing different products.

Rates vary by region and seniority, and the amount of rework depends on how clear the requirements are before building starts. A senior team with a clear brief can cost less in total than a cheaper team that rebuilds features twice because the scope kept moving.

What teams often get wrong

• Asking for a price before writing down scope, then treating the first number heard as the budget.
• Counting screens instead of behavior. A simple-looking screen can hide permissions, calculations and integrations.
• Forgetting everything around the app: admin tools, the backend, notifications, analytics, store review, privacy policy and terms.
• Ignoring running costs: hosting, AI inference, third-party subscriptions and maintenance.
• Comparing a fixed quote from one vendor with an hourly estimate from another without checking they describe the same scope.
• Assuming AI app builders make development nearly free. They reduce interface cost; production work such as authorization, payments and monitoring remains.

The main cost drivers

Every credible estimate is built from the same handful of drivers. If an estimate does not mention them, ask how they were handled.

• Platforms: web, iOS, Android, or all three. Cross-platform frameworks reduce duplicated code, but not testing, store submission or platform-specific features.
• Roles and permissions: one type of user is much simpler than customers, staff, admins and organizations with their own members.
• Integrations: payments, CRM, maps, calendars, messaging and identity providers. Each adds configuration, error handling and testing.
• Data and backend: real-time sync, offline support, file handling, search and reporting.
• AI features: a single model call inside an existing feature is modest. Retrieval over your documents, evaluation, voice, and agents with tool permissions and safety controls are substantial work.
• Compliance and security: health, finance, children's data and regional data-protection requirements add design, review and documentation work.
• Design depth: a template adapted to your brand versus a custom design system.
• Quality bar: automated tests, staging environments, monitoring and accessibility.

Illustrative ranges and their assumptions

The ranges below are illustrative, not quotes or guarantees. They exist to show how scope translates into effort. Assumptions: a small senior team or founder-led studio, a blended rate between $60 and $120 per hour, scope agreed before building, and estimates that include design, development, quality assurance and first deployment. They exclude marketing, legal review, content creation, app store fees and ongoing hosting.

• Clickable prototype or validated design: roughly 40 to 150 hours, or about $2,400 to $18,000. Screens and flow, no production backend.
• Focused MVP on one platform: roughly 250 to 600 hours, or about $15,000 to $72,000. Authentication, one core workflow, basic admin, one payment or messaging integration, deployment.
• Cross-platform product (web plus iOS and Android): roughly 600 to 1,400 hours, or about $36,000 to $168,000. Multiple roles, payments, notifications, an admin dashboard and analytics.
• AI-heavy product: roughly 800 to 2,000 or more hours, or about $48,000 to $240,000 and up. Retrieval, an evaluation harness, voice or agents with tool permissions, and cost controls.

The arithmetic is deliberately visible: hours multiplied by blended rate. If your market's rates differ, or your scope includes items listed as excluded, the range moves accordingly. The width of each range reflects real uncertainty at the one-sentence stage; a written brief narrows it.

A worked example

Consider a hypothetical appointment app for a single clinic: patients book and cancel on iOS and Android, staff manage a calendar on the web, payments are taken at booking, and reminders go out by email and push notification. Break it into features and estimate each with a low and high figure: authentication and roles, booking flow, staff calendar, payment integration with webhook handling, notifications, admin settings, analytics, testing and store submission. Suppose the sum lands between 500 and 900 hours. At the assumed blended rate of $60 to $120 per hour, that is roughly $30,000 to $108,000. The number itself matters less than the list: each line can be questioned, cut, deferred or firmed up, which is how the range narrows before anyone signs a contract.

Running costs after launch

Budget separately for what the app costs to operate. Hosting and databases are often modest at launch and grow with usage. AI inference is billed per use, so estimate it from expected tasks per user rather than a flat number. Add third-party subscriptions, app store developer accounts, monitoring, and maintenance for operating system updates, dependency upgrades and security fixes. A practical approach is to reserve a yearly maintenance budget from the start and revisit it after a few months of real usage data.

Implementation considerations: getting a reliable estimate

Write a one-page brief before asking for prices. Cover the users and roles, the one workflow that must work on day one, the integrations, the platforms, how sensitive the data is, the deadline and what is explicitly out of scope. The project brief walks through those questions in six steps.

Ask for estimates as ranges per feature, with assumptions and exclusions listed. A vendor who gives one number without assumptions is either padding for risk or guessing, and you cannot tell which.

Pay for discovery when uncertainty is high. A short paid scoping phase that produces user flows, a data model and a risk list makes the build estimate much tighter and gives you something useful even if you choose another team.

Phase the build. Agree on an MVP scope, list deferred features separately with their own ranges, and decide what evidence would justify building them. This keeps the first budget honest and gives you a plan for the second.

Trade-offs

Fixed price gives budget certainty but encourages vendors to add contingency and resist change. Time and materials is flexible but needs trust, visibility and regular demos. Many teams use fixed price for discovery and a well-defined first phase, then time and materials once the product is learning from users.

Lower hourly rates can mean more hours, more rework or more of your time spent managing. Cross-platform frameworks save duplicated work but can add effort for platform-specific features. AI app builders reduce early interface cost, but the production work described above still has to happen before real customers depend on the app.

Lessons from ImadDhin work

These are code-level and scope observations from public work, not client budgets or outcomes.

The public FoCoCo case study lists its scope: a Flutter Phone App, a Next.js WebApp, a Firebase backend, real-time voice, memberships and a public website. Each of those is a separate line in any honest estimate: two clients, a backend with security rules, a voice pipeline, a billing integration with entitlements and a marketing site. Describing it as 'a golf coaching app' would hide almost all of that work.

The ImadDhin portal shows how integrations accumulate: booking, CRM, transactional email, newsletter, analytics, payments and error monitoring. Each is quick to connect and slower to make reliable, because each needs configuration per environment, failure handling that does not block the user, and documentation so someone else can maintain it. Operator setup notes for several integrations live in the repository for exactly that reason.

Common mistakes to test for in an estimate

• Does it list what is excluded, not just what is included?
• Are the backend, admin tools and deployment included, or only the screens?
• Is quality assurance a named line item?
• For mobile, are store submission and review rounds included?
• Are AI running costs estimated separately, with usage assumptions stated?
• Who owns the code, cloud accounts, store accounts and data at the end?
• How are scope changes priced once work has started?

When a simpler solution is better

If a spreadsheet, a form and an automation tool can run the process for your first customers, start there and learn what the app actually needs to do. If an off-the-shelf product covers most of the workflow, configuring it will usually cost less than building. And if you are still testing demand, an AI app builder prototype or a landing page with a waitlist is a cheaper experiment than an MVP.

Build custom when the workflow is central to your business, when existing tools force painful workarounds, or when you need control over data, behavior and user experience that products cannot give you.

Get an estimate you can defend

A good app estimate is a list of drivers and assumptions, not a single number. To see how scope, phases and handover are structured, read about AI product development and the available engagement models. When you have a draft brief, bring it to a 30-minute call and we will walk through the drivers together.