How much does app development cost, and how to estimate it yourself

Every agency site has a page like this, and most are useless — a wide range, a “contact us for a quote”, and no explanation of what moves the number.

Here is the version that actually helps: what drives cost, how to estimate your own project roughly before speaking to anyone, and how to tell a real quote from a fictional one.

Why nobody can quote you from a one-line description#

“A marketplace app like Uber but for X” can be a twelve-week build or a two-year build. The difference is not the idea. It is:

• Do drivers and riders both need apps, or is one a web dashboard?
• Is payment in-app, or handled outside?
• Real-time location, or periodic updates?
• Does it work offline?
• One country or several — currencies, languages, tax rules?

Each answer swings the estimate by weeks. Anyone quoting before asking these is guessing, and you will meet the real number later as change requests.

The five things that actually drive cost#

1. Number of user types#

This is the most underestimated multiplier. Each distinct role — customer, provider, admin, support — needs its own screens, permissions, and testing. Two roles is not twice one role, but it is not far off.

2. Whether a backend exists#

If you have a working API, an app is an app. If not, you are building a server, database, authentication, admin tools and deployment alongside it. That often doubles the project.

3. Real-time features#

Chat, live tracking, notifications that must arrive immediately, collaborative editing. Each moves you from simple request-response into infrastructure with meaningfully harder failure modes.

4. Payments and money#

Taking a card once is simple. Subscriptions, refunds, partial refunds, failed renewals, proration, marketplace splits, tax — that is a project inside your project.

5. Integrations#

Every external system is unknown until someone reads its documentation and hits its limits. Well-documented modern APIs are fine. Enterprise systems, legacy hospital software and bank interfaces are not, and cannot be estimated from the outside.

Estimate your own project first#

Rough method, in engineering-weeks rather than currency, since rates vary enormously by market:

1. Count your screens. Not variations — distinct screens. Under 15 is small, 15–40 medium, over 40 large.
2. Count user roles. Multiply your screen count by roughly 1.4 for each role beyond the first.
3. Add backend. No API yet? Add 60–100% to the total.
4. Add for each hard feature. Real-time, payments, offline sync, third-party integration: 2–4 weeks each.
5. Add 30% for the things nobody lists. Onboarding, error states, empty states, settings, password reset, app store review, analytics.

Step 5 is where most estimates die. The features people describe are the interesting ones. The plumbing between them is half the work and is invisible in every project description we have ever received.

A rough anchor: a small app with one role, an existing backend and no hard features lands around 6–10 senior engineering weeks. Multiply by your team’s weekly rate.

How to read a quote#

A quote far below the others is not a bargain. It usually means the scope was misunderstood, or the plan is to win on price and recover margin through change requests. The second is a business model, not an accident.

A quote with no assumptions listed is not a quote. A real estimate says what it assumed: the API exists, designs are provided, one language, no offline mode. Those assumptions are where the truth lives.

Ask what they are least confident about. An honest team names something specific — usually an integration. A team that says they are confident about everything has not thought about it.

Fixed price is not the same as low risk. Fixed price means the vendor priced their risk into the number and will defend the scope line by line. That can be right for genuinely stable requirements, and painful for anything exploratory.

The cheapest decision available to you#

Not offshore. Not a framework. Building less.

Most first versions carry two to three times the features they need to validate the idea. Every one you defer is weeks saved, a shorter path to real users, and one less thing to rewrite when those users contradict your assumptions.

When we quote, we usually propose a smaller scope than the one we were sent. That is not modesty about our capacity — it is that the smaller version reaches real users sooner, and real users change the plan more than any workshop does.

What to send an agency for a useful estimate#

You will get a far better number if you provide:

• A list of screens, even rough
• The user roles and what each can do
• Whether a backend or API already exists
• Any systems it must integrate with, with documentation links
• Platforms — iOS, Android, web, or some combination
• Your actual deadline and what drives it
• Your budget range

That last one causes hesitation, because people fear being quoted up to their budget. Reasonable worry. But without it, an agency cannot tell you whether your project is feasible at your price — and finding that out in month three is far more expensive than an awkward first conversation.