How much does it cost to build an app? Estimate from scope

Search for what an app costs and you will find ranges that run from a few thousand to several hundred thousand, quoted with confidence. Those numbers are averages over very different products, and an average of different things is not an estimate of yours.

This post does not give you a price. It shows why quotes differ, what drives the number, and how to build an estimate from your own scope, with a worked example you can copy. The example is arithmetic, not market data.

Why two quotes for the same app can differ so much

Vendors are rarely pricing the same thing. The gap usually comes from:

• Different scope. One quote includes an admin panel, notifications and payments. Another assumed they were out. The brief said "an app" and each read it differently.
• Different quality bars. Automated tests, security review, accessibility, documentation and a proper handover all take time. A quote that leaves them out is cheaper and does not include them.
• Different rates. Location, seniority and agency overhead each move the day rate.
• Different risk allowances. A team that has built something similar can estimate tightly. A team that has not adds a margin, or ignores the risk and pays for it later.
• Who carries the change risk. A fixed price can be lower because the vendor expects change-order arguments later. Time-and-materials costs what it costs, and you see it as you go.
• Different exclusions. Design, the backend, hosting, releasing to the stores and post-launch support are each sometimes in and sometimes out.

Notice that only one of these is the rate. Comparing "price per hour" misses most of the difference.

What actually moves the number

Cost is mostly effort, and effort comes from a short list of drivers:

• User roles and permissions. Each role multiplies screens and rules.
• Number and depth of screens and flows, and how much business logic sits behind each.
• Platforms. iOS, Android, web and an admin panel are each real work, even when a cross-platform framework shares a lot (how to choose one).
• Integrations. Payments, maps, identity, your existing systems. Each has its own documentation, limits and edge cases, and the third-party ones are the classic source of surprises.
• Real-time features. Chat, live updates or video calls add architecture, not just screens.
• Data. A new schema is one thing; migrating messy existing data is another.
• Compliance and security. Health, payment or children's data adds requirements that shape the design.
• Design depth. A standard component set is quicker than a fully custom design system.
• Accessibility. Built in from the start it is a normal part of the work; retrofitted it is usually more expensive (accessibility-aware development).
• The admin back office. Frequently forgotten in the first budget and always needed.

Estimate it yourself: the three-point method

You do not need special software. Break the app into work items, and for each one write three numbers in person-days:

• Optimistic (O): it goes smoothly.
• Most likely (M): the honest expectation.
• Pessimistic (P): the known risks come true.

Then combine them with the weighted average used in three-point (PERT) estimating:

Estimate = (O + 4 × M + P) ÷ 6

The weighting leans towards the likely case while still pulling in the risk of a long tail, and the width of O to P tells you where the uncertainty is. Wide ranges are the parts to investigate first.

A worked example

Take a hypothetical booking app with payments and an admin panel, for iOS and Android. The days below are invented for the arithmetic. They are not a benchmark, and a real project's numbers depend on its scope and team.

Work item	O	M	P	Estimate
Accounts, roles and sign-in	3	5	9	5.3
Core workflow: six screens and the rules behind them	12	18	32	19.3
Payment integration	4	7	15	7.8
Email and push notifications	2	4	8	4.3
Admin back office	6	10	20	11.0
Testing, fixes and release to both stores	6	9	16	9.7
Total	33	53	100	57.5

Estimates are rounded to one decimal place; the total is computed from the unrounded values.

Three things to read from it:

1. The total is a range, not a number. Depending on how things go it is anywhere from 33 to 100 person-days. Adding the pessimistic column overstates the risk, because every item rarely goes wrong at once, but the width is real.
2. The weighted figure (57.5) sits above the "most likely" sum (53). That is the tail showing up, and it is the reason to add the risk instead of pretending it is absent.
3. Cost = days × your blended day rate. Keep the rate separate from the days. If two vendors quote the same app, compare their days by line item first, then their rates. The days show whether they understood the scope; the rate shows what their time costs.

Some teams add a contingency on top. Its size should follow how uncertain the scope still is, not a fixed percentage. A well-understood app needs little, and a vague brief needs a lot, which is the argument for narrowing the scope before you sign.

The costs after launch

Budgets that stop at "build" are wrong. Budget for these too:

• Hosting and cloud services, which grow with usage.
• Third-party charges. Payment fees, SMS, email, maps, video minutes, push services. Many are per use.
• App store accounts and fees. Check the current ones.
• Maintenance. Operating systems change every year, and dependencies need updates and security patches. An app left alone slowly stops working.
• Support and monitoring: someone has to see errors and answer users.
• Your own team's time: reviews, feedback, content, rollout and training.
• Data migration, legal documents (privacy policy, terms) and any compliance work.

How to lower the cost without lowering the quality

• Cut scope, not quality. Removing a feature saves its whole cost. Skipping tests only defers it, with interest. See what to build first.
• Phase it. Ship the core flow first and learn from real use.
• Start on one platform if your users allow it.
• Buy the commodity parts. Sign-in, payments and email are solved problems with services you can rent.
• Answer questions fast. Waiting for feedback is a cost too.
• Do a short, paid discovery first. Spending a little to remove the largest unknowns usually costs less than building on a wrong assumption. See choosing a development partner.

If a low-code or no-code tool covers a prototype or a simple internal tool, it can be the cheapest sensible answer. Price its limits too: performance, integrations, who owns the result, and what leaving costs.

What to ask each vendor for

For every quote you collect, ask for the same thing:

1. Days by line item, and the rate, separately.
2. The assumptions the estimate relies on (what your team must provide, and by when).
3. The exclusions, in writing.
4. A range, not a single number, for anything still uncertain, and what would narrow it.
5. What is included after launch, and what a bug fix costs versus a change.

A vendor who cannot break a price into pieces has not estimated it.

Frequently asked questions

How much does a simple app cost? There is no honest single figure, because "simple" means different things. Break your app into items as above; a simple app is one with few roles, few screens and few integrations, and the estimate follows from that.

Why is the cheapest quote often not the cheapest project? Because it usually leaves things out (testing, admin, handover) or assumes a scope you did not intend. The gap appears later as change requests, or as rework.

Is fixed price or time-and-materials better? Fixed price suits a stable, narrow scope. Time-and-materials suits work still being shaped. Either way, ask for milestones with a working demo at each.

Does an AI or no-code builder make custom development unnecessary? For prototypes and simple internal tools it can. Check what you would give up, such as integrations, performance, ownership and the ability to move later.

How long does it take? The same days feed the schedule, but people do not work in parallel without limit. Ask the vendor how many people the estimate assumes.

Where to go from here

If you would like this done for your project, send us the problem, the users and the deadline. We will reply with the questions we would ask before we put a number on anything. Send requirements, or if you are an early-stage team, see custom software development for startups.