How much does it cost to build an app?
The short answer is $15,000 to $90,000 for most projects. The useful answer is which end you are on, and why.
- $15K – $90K
- What most custom applications cost
- 550 – 1,100 hrs
- The hours behind $30,000 and $60,000 at that rate
- $55 / hr
- Blended across design, engineering, QA, and management
Numbers first, reasoning after. The answer does depend on a handful of things, and this page names them, but you can have the ranges before you read a word of explanation.
These are ranges for custom software built by a professional team: design, engineering, testing, and someone accountable for the schedule. A template costs less. So does an offshore hourly rate multiplied by an optimistic guess, right up until you compare what arrives.
The short answer
Three project shapes cover most of what gets built. Find the description that sounds most like yours.
$15,000 – $25,000
A focused first version
About 9–15 weeks
One thing done properly, for one kind of user, with a new backend behind it. Enough to put a real product in front of real people and learn something you could not have guessed.
$30,000 – $55,000
A production application
About 3–5 months
Several workflows, more than one type of user, and an administrative side for the people running it. This is where most software that gets used every day lands.
$55,000 – $90,000
A complex build
About 4–6 months
Works offline, talks to hardware, integrates with a system you already run, or handles regulated data. Any one of these puts you here. Two of them and the top of the range is the starting point.
These are the three shapes of project that show up most often. Treat the boundaries as soft: work lands between the bands constantly, and a project can sit at the top on one dimension and the bottom on every other. The calculator prices the description you give it instead of sorting you into a box.
Why the range is that wide
The width comes from the phrase itself. "An app" describes a five-screen utility and a warehouse system used by sixteen thousand people, and nothing in those two words separates them.
Two apps with the same number of screens can require wildly different engineering. Take a screen that shows today’s jobs. Version one fetches a list from an endpoint and draws it. Version two has to work in an elevator, hold the list on the device, let the user complete a job while disconnected, then reconcile the result against changes a dispatcher made to the same record from an office. The wireframes are indistinguishable. One is two weeks of work and the other is two months.
This is why a single confident number deserves suspicion. A figure with no range attached tells you how much the estimator was willing to say out loud, and nothing about how much is still unknown.
What you are actually paying for
You are buying hours at a rate. The rate behind these numbers is $55 an hour, blended across design, engineering, QA, and project management. It is a blend rather than a set of per-role rates, because a preliminary estimate cannot know the staffing mix, and pretending otherwise adds precision without accuracy.
- 550 hrs
- What $30,000 buys at the blended rate
- 1,100 hrs
- What $60,000 buys at the blended rate
At that rate, a $30,000 project is roughly 550 hours of work and a $60,000 project is roughly 1,100. It is worth converting any quote you receive into hours, because hours are comparable between firms and headline prices are not. If two proposals differ by $20,000, the hours will tell you whether you are looking at a different rate or a different project.
Those hours divide across eight kinds of work, and a quote that does not name them is hiding at least one.
Discovery and architecture: turning the idea into a scoped, buildable plan.
Product and UI design: screens, states, and a design system, reviewed before anyone writes production code.
Application development: the app itself, meaning screens, navigation, state, device behavior, and release builds.
Backend and data: APIs, the data model, storage, authentication, environments, deployment.
Integrations: connecting to systems you already run, and handling it when they misbehave.
The admin application: the office-facing side, which is effectively a second product.
QA and release: device testing, edge cases, store submission, and the review cycles after it.
Project management: planning, coordination, demos, and keeping scope and schedule honest.
The last two are shares rather than fixed figures: QA runs at 10–13% of everything there is to test, project management at 7–10% of the whole. A proposal missing both is about 20% short before anyone has argued about a feature.
The four questions that move the number most
Answer these before you speak to anybody and you will get quotes worth comparing, because everyone will be pricing the same project.
- 1. Do you already have a backend?
- A finished, documented API takes the server-side work down to roughly a third of building one from scratch. A partial one, which is the usual answer, helps much less, because the missing part tends to be the part your app needs. Be specific: "we have an API" and "we have a database and an internal tool that reads it" are very different answers.
- 2. How many different kinds of user are there?
- Not how many users. How many kinds. One is the baseline; the second one costs money, because it brings its own screens, its own permission rules, and its own test pass. Four kinds of user is a much larger project than two, and it is the most common source of quiet scope growth after a project starts.
- 3. Does it have to work without a network, or talk to hardware?
- Either of these moves a project up a band on its own. Offline means local storage plus synchronization plus conflict resolution plus testing on bad networks. Hardware means pairing, permissions, protocol work, and a test pass on real devices in the states they fail in.
- 4. Is regulated data involved?
- Health records, card data, government work, or a formal accessibility conformance requirement. Each of these changes how the software is built rather than what gets documented at the end, adds somewhere between 5% and 35% depending on the regime, and turns into a rebuild if you retrofit it later.
What the very cheap number leaves out
A quote dramatically below these ranges is usually a smaller scope wearing the same words. The gap is normally made of the same four things.
The admin application, described in one sentence and priced at zero, then rediscovered as "phase two" at close to the cost of the app itself.
QA beyond the developer checking their own work, which finds a fraction of what your users will.
Project management, which stops being billed long before it stops being needed. Then you do it, for free, in the evenings.
Discovery, cut on the grounds that the requirements are obvious. They are obvious right up until two people who both understood them perfectly turn out to have understood them differently.
The way to compare quotes fairly is to ask each one for hours by workstream. It is a reasonable request, it takes an honest firm ten minutes, and the response tells you as much as the number does.
How long it takes
A focused first version is usually 9–15 weeks. A production build is 3–5 months, and a complex one 4–6. Those are elapsed calendar weeks with a real team on it, instead of hours divided by an idealized working day.
- 2–3 weeks
- Fixed at the ends: kickoff, your review cycles, and store review
- 8 weeks
- The floor, whatever the arithmetic says
Two to three of those weeks are fixed no matter how the project is staffed: kickoff and discovery, your own review cycles, and app store review at the end. Adding engineers compresses the middle of a project and does nothing to the ends. A two-week wait for a decision on your side costs two weeks whether one person or six are waiting for it, which is why the fastest projects are usually the ones with a single available decision-maker rather than the ones with the biggest team.
What happens after you launch
Spending continues after launch, and a plan that assumes otherwise gets surprised around month eight. Apple and Google ship operating systems every year. Dependencies and SDKs go out of support. Store policies change with deadlines attached. Bugs appear that only exist at real volume, and real users immediately suggest changes nobody thought of.
- 15–20%
- Of build cost per year — an industry convention, not a calculator output
A common planning figure is 15–20% of the build cost per year for an application in active use, less if it is stable and nobody is asking for anything new. That figure is a convention rather than something this calculator computes; the estimate here covers building the thing rather than running it. Put a number in the slot before you commit to the build.
Common questions
How much does it cost to build an app?
Most custom applications cost between $15,000 and $90,000. A focused first version with one workflow and one type of user is usually $15,000–$25,000. A production application with several workflows, multiple user types, and an admin portal is usually $30,000–$55,000. Offline operation, hardware, integrations with existing systems, or regulated data push a project to $55,000–$90,000 and sometimes beyond.
Can I build an app for $5,000?
Not with a backend, two platforms, and someone answering the phone when it breaks. What $5,000 buys is a clickable prototype, a template with your branding on it, or the first month of a project that needs eleven more. A prototype is a legitimate purchase for testing an idea, as long as you are buying it knowingly as a prototype rather than as a discounted app.
How much does it cost to maintain an app?
A common planning figure is 15–20% of the build cost per year for an application in active use. That covers annual OS releases on both platforms, dependency and SDK updates, store policy changes, defects that only appear at real volume, and small improvements. An app nobody touches for eighteen months is drifting, and the bill for that arrives all at once.
Should I get a fixed price or pay hourly?
A fixed price is the same price with the risk transferred and a margin added for carrying it. It works well when the scope is settled and both sides can describe exactly what "finished" means. It works badly when the scope is still moving, because every change becomes a negotiation and the incentive on the other side quietly shifts from building the right thing to building the agreed thing.
Why is this calculator free?
It was built by ANTLR Interactive, who design and build custom software for a living. A conversation with someone holding a realistic budget is better than one with someone holding a fantasy, whether or not that conversation happens with us. The estimate itself is free and complete, with nothing held back for a follow-up call. Your name and work email at the last step are the price of it, and they go to ANTLR along with your project description.