Every app quote you receive will be different, and the range will be wide enough to be unhelpful. The reason is that almost nobody prices the app. They price the assumptions they had to make because the specification was not clear enough to price against.
How much does it cost to build an app?
A simple app with a handful of screens, no backend of its own and no integrations sits at the low end. A marketplace or a fintech product with user accounts, payments, notifications, an admin system and compliance requirements sits at the high end, and the gap between them is an order of magnitude rather than a percentage. Nothing about that is evasive. It is the same reason nobody can price a building without knowing how many floors it has.What actually drives the cost?
Number of distinct screens, and how many of them are bespoke. Ten screens sharing three layouts cost far less than five screens where every one is different. Whether you need a backend. An app that reads from an existing system is much cheaper than one that needs its own database, authentication, admin interface and hosting built alongside it. Integrations. Payments, mapping, messaging, a CRM, an existing ERP. Each one is a separate system with its own failure modes, and they are usually the single largest variable in a quote. Platforms. iOS and Android from one cross-platform codebase costs less than two native builds, at the price of some platform-specific polish. For most business apps that trade is worth taking. Compliance. Handling health data, financial data or children's data changes the engineering and the testing, over and above the paperwork.Why do quotes for the same app differ so much?
Usually because each agency has quietly scoped a different app. One assumed you have brand assets and a designer, another priced design in. One assumed an existing backend, another priced building it. One included six months of support, another stopped at launch. When quotes differ by a factor of three, the specification is doing the varying, not the market rate. Comparing them like for like means writing the specification down first and giving the same document to everyone.What is usually missing from the number you were quoted?
App store fees and the developer accounts. Backend hosting, which is a monthly cost for the life of the app. Ongoing maintenance, because iOS and Android both ship breaking changes annually and an unmaintained app degrades whether or not you change anything. Then the things that are easy to forget at quote stage: analytics, crash reporting, customer support tooling, and the content or data the app needs on day one.You may not need an app at all
Often not, and any agency worth hiring will say so before taking your money. A well-built responsive website does most of what a business app does, costs considerably less, needs no app store approval, and does not require the user to install anything before they can buy from you. An app earns its cost when you need offline capability, device hardware such as camera or location running in the background, push notifications as a core mechanic, or genuine repeat usage where an icon on a home screen changes behaviour. If your use case is none of those, web development is usually the better purchase and the faster route to market.Keeping the project from overrunning
Write the specification before asking for prices, and be specific about what happens in the unhappy paths rather than only the demo flow. Agree what is explicitly out of scope, which is more useful than another page describing what is in it.Where does the money actually go?
On most projects the split is roughly a quarter to design and specification, half to engineering, and the remainder to testing, project management and release. The engineering share is the one people expect. The specification share is the one that gets cut, and cutting it is what makes the engineering share grow. Testing is the other quiet cost. An app runs on hardware you do not control, in operating system versions you cannot pin, on connections that drop mid request. The difference between a demo and a product is mostly the handling of everything that can go wrong, and that work is invisible in a specification written around the happy path.Fixed price or time and materials?
A fixed price transfers risk to the agency, and the agency prices that risk in. It suits projects where the specification is genuinely settled and you want certainty more than flexibility. Time and materials suits projects where the shape will change as you learn. It is usually cheaper for the same output, on the condition that someone on your side is actively managing scope. Without that, it becomes the more expensive option. Neither is inherently better. What matters is matching the model to how settled the specification actually is, rather than to how settled everyone would like it to be.Questions worth asking before you sign anything
What exactly is out of scope. Who owns the repository and the app store accounts. What happens if a platform ships a breaking change during the build. What the handover includes beyond the code itself, meaning documentation, environment setup and access to every third party account created along the way. Then ask what they would build first if the budget were halved. The answer tells you whether they understand the product or only the feature list. Build the smallest version that a real user can complete a real task in, then put it in front of users before building the rest. Most of the budget lost on app projects is spent building features nobody had validated. It is also worth being clear about what a quote is not. A number produced before anyone has seen your data model, your existing systems or your users is a range dressed up as a price. Treat an early number as a filter for whether to keep talking, not as a commitment either side should be held to. The most useful thing you can do before approaching anyone is write down the three things a user must be able to do, in order, on day one. Not the feature list. The journey. Almost every app that overran its budget did so because that document did not exist and the feature list stood in for it. If an agency reads that document and comes back with questions about the awkward cases, the ones where a payment fails or a user loses connection mid task, they are pricing the real product. If they come back only with a number, they are pricing the demo. Budget for a second phase from the start. Almost no app is finished at launch, and the most valuable changes are the ones you could not have predicted because they come from watching real people use it. Holding back a portion of the budget for that is more useful than spending all of it on features chosen in advance. Our app development team quotes against a written specification for exactly this reason. If the specification is not clear enough to price, that is a finding worth having before you commit a budget rather than three months in.FAQ
Frequently asked questions
- A simple app is typically two to four months. A complex product with its own backend and multiple integrations runs six months or more. Timelines usually slip because the specification changed during the build, not because the engineering was slower than expected.
