There is no figure in this article, and the reason is not coyness. It is that the question as asked cannot be answered, because two projects that people describe with the identical sentence — "we need an app" — differ in cost by roughly ten times.
Any single number that covers both is useless in the same way an average is useless when the data has two clusters. What is genuinely useful is working out which cluster you are in, and that takes about ten minutes of honest thinking. This article is that ten minutes.
The two products people call an app
Almost every enquiry is one of these. They share a technology and nothing else — different cost, different timeline, different risk, and different reasons to fail.
The consumer app. Public, on both stores, for people who do not work for you. Two-sided marketplaces, booking platforms, anything with sign-up and a payment. We built one of these called Just Book: a Flutter app on iOS and Android, a web platform, shared APIs, postcode-and-category search, in-app chat with quotes, secure payment and a six-stage booking tracker. It took five months, and the engineering was the tractable part.
The internal tool. Private, for your own staff, replacing a clipboard or a spreadsheet. Job scheduling, client records, site reports, invoices raised from a van. We built one of those too — RapidKill, an admin app for field-service businesses, Flutter and Firebase, clients and jobs and invoices as one connected record, client-ready PDFs emailed from site. Six weeks, blank repository to users' hands.
Six weeks against five months. That is the gap any single cost figure has to span, which is why nobody publishing one is telling you anything.
Why the internal tool is usually the better buy
A large share of people who arrive asking about a consumer app actually want the second thing and nobody has told them it exists at that price. It is worth being blunt about why the internal tool wins so often.
It has no marketing problem. A consumer app has to be found, downloaded, opened, and opened again — and the app itself does nothing to make any of that happen. That is a customer acquisition problem, it is usually larger and more expensive than the build, and it is the reason most consumer apps fail commercially while working perfectly. An internal tool has a captive audience who are required to use it, so the only question is whether it saves them time.
Its return is measurable. A report that leaves site with the technician rather than a fortnight later, an invoice that follows it the same day, a scheduling change that does not require three phone calls. You can put a number on those before you commission anything, and you can check it afterwards.
And it can be private. An internal app does not have to be listed publicly at all — it can be distributed straight to your own devices, which removes the store review cycle entirely and lets you ship changes on the day you want them rather than after somebody else approves.
What moves the price, once you know which one you are building
In rough order of impact.
How many screens have real logic behind them. Not screen count — logic count. Twenty screens that display information are a fraction of the work of five that take input, validate it, talk to a payment provider and handle failure. When you sketch your app, mark every screen where something can go wrong. That marked subset is your project.
Whether there is a back end, and whether it exists yet. Most apps are a client of an API somebody has to build, and that server-side work is frequently more than half the total. If you already have a system with a usable API, you have removed a large share of the cost. If your data currently lives in a desktop application in an office, that is a separate project that has to happen first.
Accounts, payments and the boring half. Sign-up, password reset, roles, an admin view for your support person, and payment handling including the failure cases. This list is nearly identical for every app, it is most of the work, and a quote that does not mention it is a quote for a demo.
One codebase or two. Building separately for iOS and Android roughly doubles the client-side effort and there are still projects that justify it — heavy graphics, deep platform integration, hardware. For most business apps a single cross-platform codebase gets you both stores from one build, which is why both of the projects above were done that way. The trade-offs are argued out properly here rather than assumed.
Store submission, if it is public. Both Apple and Google reject first submissions routinely, for reasons unrelated to whether the app works: a missing privacy declaration, no test account for the reviewer, a permission requested without explanation. This is planned-for rather than feared, but it takes time and it belongs in the schedule. If a proposal ends at "delivery of the build", ask who does this.
The cost after launch, which is the one people forget
An app is not a purchase, it is a thing that needs keeping alive, and this is where budgets are quietly broken in year two.
Both platforms ship a major operating system update every year and something will break. Certificates expire, and an expired one can take your app out of the store. Store policies change, and compliance is retrospective — an app that was fine last year can be non-compliant this year. Any back end has hosting. Any third-party service in your app has a bill attached.
Plan for a maintenance arrangement or an in-house developer from launch day. The number is real, it is recurring, and an agency that has not raised it before you did has either not thought about it or is hoping you will not ask.
How to read the quotes
Three checks make wildly different numbers comparable.
Find the exclusions. Design, content, the back end, store submission, and post-launch support are the five things that live in the gap between a cheap quote and an expensive one. A proposal with no exclusions section is not a quote.
Ask whose name is on the developer accounts. The only good answer is yours, with the agency added as a collaborator and removable at the end. An agency that registers your listing in their own account owns your reviews, your ranking history and your ability to ship an update. Recovering a listing later is a genuinely miserable process and it is entirely avoidable by asking now.
Ask what month thirteen costs. Ask every agency on the shortlist and compare the answers. The one that has a considered figure has built apps that lasted; the one that looks surprised has not.
Does the UK part change anything?
Not in engineering terms. An app is an app. What is specifically British is a short list that matters for consumer apps and barely at all for internal tools: postcode-first search, because that is how people here look for anything local; payment sheets that feel familiar; and privacy declarations on both stores that accurately match what your app collects, where over-declaring is as much a rejection risk as under-declaring.
What does move the price is where the people building it are, and that is a real difference rather than a quality signal. Compare scope for the money, who owns the accounts, and what happens when something breaks at an awkward hour.
Getting a number for your project
Decide which of the two products you are buying. Sketch the screens and mark the ones with logic. Establish whether a back end exists. Write down every external system it must talk to. With those four things, three studios will price the same project and the numbers become informative rather than random.
We do this as a free written teardown inside 48 hours, and it includes the part that costs us money to say — an honest read on whether you want the consumer app or the cheaper internal tool. If you want to see the two shapes side by side first, both are set out with their timelines on the apps page. If the thing you actually need turns out to be a platform rather than an app, that work is described here.
