Cost to build an app: the four decisions that move it

Clutch's own Software Development Company Pricing Guide, updated 21 September 2026, says experienced software developers on its platform cost between $10,000 and $49,000 per project. The same page puts the average project at $132,480.29 — a figure that sits outside the range it leads with.

That contradiction is the honest answer to the question of the cost to build an app. A range wide enough to be true is too wide to budget against. We publish no price bands and we will not quote from a one-line brief. What we can do is make you better at estimating your own build, so you can read anyone's proposal properly — ours included.

Four decisions move the figure more than anything else: how much scope the first release carries, how many platforms you ship, how messy your integrations and data are, and which compliance regime applies. Everything else is a consequence of those four.

Decision	Cheapest version of it	Most expensive version of it
Scope of the first release	One user role, one core journey, proven end to end	Customers, staff, partners and administrators all served on day one
Platforms	One web app on one shared backend	Web, iOS and Android, each designed, built and tested separately
Integrations and data	A modern, documented payment API	Years of data migrated out of a legacy system, or an undocumented internal tool
Compliance and security	Ordinary authentication and access control	HIPAA, PCI DSS or data residency obligations, with evidence to produce

Why nobody will quote the cost to build an app from your brief

An estimate is a claim about work, and work cannot be inferred from an outcome. "A booking app" describes a result. It does not say whether one person books for themselves or a venue manager approves against an inventory that three other systems also write to. Those two products share a name and almost no engineering.

So a vendor who quotes from your first email is doing one of two things. They are padding, to be safe against whatever you turn out to mean. Or they are quoting the cheap reading of your sentence, which lands as a change request six weeks later. Neither is a price; both are a negotiating position.

What we do instead is a free discovery call, then a short discovery session, and the output is a fixed-scope proposal with a budget breakdown, milestones and a timeline. The number arrives after the scope, because it is derived from it.

Scope is the decision that moves every other one

Count user roles before you count features. Each role is its own set of screens, its own permissions, its own test matrix and usually its own onboarding. A role is not a filter on an existing interface; it is a reason the interface exists at all.

The shape of this is visible in our own work. Nomina, an enterprise HR and payroll platform, carries 13+ core modules across 5 user roles and reached market in 20 weeks. MakeMyLook, a salon and wellness booking marketplace, onboarded 200+ vendors and shipped in 16 weeks. Both are real products. The difference between them is not quality or effort per week — it is how many distinct people the first release had to serve.

This is also where the honest lever sits. A focused MVP that proves one core journey typically takes 6-10 weeks. Larger enterprise platforms typically take 3-6 months, depending on complexity, integrations and scope. If your budget is fixed and your scope is not, the scope is the variable you have.

Each platform you add is a build, not a copy

A web app, an iOS app and an Android app can share one backend, and that sharing is real: the data model, the business rules and the API are written once. Cross-platform frameworks such as React Native and Flutter cut mobile effort further by sharing most of the client code too.

What they do not share is the part that costs. Each surface still needs design decisions that suit its conventions, its own device and screen testing, its own release pipeline, and its own store review. Our AI-powered sales training platform for Škoda Auto's dealership network is 3 platforms serving 100+ dealerships, built with Flutter, React, TypeScript, Node, PostgreSQL and AWS, delivered in 20 weeks. The shared backend is why 3 platforms in 20 weeks is possible at all. It is not why they were free.

The practical question is not "web or mobile". It is: which surface does the first release actually need in order to learn something? Shipping two platforms to an audience that would have used one is the most common way a budget is spent without buying information.

Integrations cost whatever the other system's documentation is worth

Integration effort tracks the quality of what you are integrating with, not the number of integrations. A modern payment API with versioned documentation, a sandbox and sensible error semantics is a known quantity. An undocumented internal tool that one person understands is open-ended work, because discovering the behaviour is the work.

Data migration out of a legacy system is the expensive case and the one most often left out of estimates. The schema has drifted from whatever it was documented as, decades of exceptions live in free-text fields, and the business rules you need to reproduce exist only as the way the old system behaves. Our legacy application modernisation work starts there for exactly this reason.

AI features span the same spread. An assistant built on a hosted model API is a bounded piece of engineering. Custom models trained on your data bring data collection, labelling, evaluation and retraining, which is a programme rather than a feature. Both get called "adding AI" in a brief.

Compliance moves cost through evidence, not features

Engineering leaders usually expect compliance to add controls. It does, but the larger cost is proving your decisions, and the standards are explicit about this in a way agency pages rarely mention.

Take HIPAA. Under the technical safeguards at 45 CFR 164.312, only two implementation specifications are marked Required: unique user identification and an emergency access procedure. Automatic logoff, encryption and decryption, integrity controls and transmission encryption are all marked Addressable. Addressable does not mean optional. It means you must assess whether it is reasonable and appropriate for your environment and document the decision — and that assessment, written down and defensible, is billable design work with no visible feature attached.

PCI DSS behaves differently again. The PCI Security Standards Council describes the standard as technical and operational requirements designed to protect payment account data, covering all entities involved in payment card processing, while noting that whether you must comply is at the discretion of organisations managing compliance programmes, such as a payment brand or acquirer. The scope that applies to you comes from your acquirer, not from the standard. Until someone asks them, an estimate that includes "PCI compliance" is pricing an unknown.

Data residency is the one that changes architecture rather than process. A requirement to keep data in a specific jurisdiction can rule out your cheapest hosting option, and it is cheap to design for on day one and expensive to retrofit after launch. A fixed launch date belongs in this group too: when the date cannot move, the only remaining variables are team size and scope, and both have a price.

What a discovery call and a fixed-scope proposal should actually contain

Demand these from any vendor, not just from us. A discovery conversation that does not cover them has not gathered enough to estimate anything.

• Who the users are, as a list of roles, with what each role must be able to do in the first release.
• Which features are must-have now and which are explicitly later.
• Every system you need to integrate with, named, with whether documentation and a test environment exist.
• What data has to come across from an existing system, and in what state it currently is.
• Which compliance or security obligations apply, and who decides their scope.
• Any date that cannot move, and what happens if it does.

The proposal that follows should then break the budget down by phase or milestone — design, core features, integrations, testing, launch — so you can see where the money goes. It should list what is out of scope. It should tie payments to milestones you can see demonstrated. And it should say how changes are handled: a written change request with its impact on scope, timeline and budget assessed before anyone commits, rather than a bill that quietly grows. Our MVP development practice works this way because the alternative moves the argument to the end of the project.

How to recognise an estimate you cannot trust

Three signals, in order of how much they should worry you.

A figure produced from a one-line brief. Nobody can price work they have not characterised, so the number is either padded or wrong, and you will not find out which until later.

A range with no scope attached to it. A band quoted before anyone has characterised your product is not an estimate of it; it is a description of the vendor's past invoices. If the range does not come with a sentence saying how many roles and platforms it assumes, it carries no information about you.

A figure that does not say what it excludes. Ask specifically: app store submission, data migration, third-party licences and subscriptions, the compliance assessment, post-launch defect fixing, source code and infrastructure handover. A cheaper quote that excludes four of those is not cheaper.

The strongest argument against all of this

It is a real one, and it is not about engineering. You may not be allowed to start a conversation without a number. Finance wants a budget envelope, a board wants a figure in a paper, and "it depends on scope" is not something you can take into that room. Every hour spent in discovery before a figure exists is an hour of your internal approval timeline, and that cost is yours, not your vendor's. A padded range that unblocks approval can be worth more to you than an accurate refusal.

The answer is not to invent a range. It is to make the first commitment small enough to approve. Phase the work: scope and price a first release that delivers the core value on its own, get that approved, and let the later phases be estimated against a product that exists rather than a description. A 6-10 week MVP is an envelope your finance team can handle, and it buys you something a range cannot — real numbers for the next decision, measured on your own build. If the full vision is larger than the budget allows, phasing is what we would propose anyway.

Which is also the practical next step, whoever you hire. Before you ask anyone what an app costs, write down the roles in your first release and the systems it has to talk to. That page is what makes a quote comparable, and if two vendors read it and come back with figures far apart, you now know enough to ask which of them read it differently. We argued the same case for one specific market in app development cost in Dubai, where the prerequisites, rather than the drivers, are what quotes disagree about.