A wrapped website is an app. So is a regulated medical device platform serving millions of people. The word "app" on its own tells you almost nothing about cost, and the question only becomes answerable once you know what sort of app you're talking about, who's building it, and which stage you're budgeting for, i.e. a prototype, an MVP or a full production app.
In this article we lay out realistic UK cost ranges for each type of app and each way of building one, the factors that move the price up or down, what developers and agencies charge, and how much to budget at each stage, including the running costs after launch, so that you can budget a realistic figure for your own app.
The short answer
A custom mobile app built by a reputable UK agency typically costs between £30,000 and £150,000 for a first release, then £6,000 to £45,000 a year to run, but there are cheaper options and more expensive options.
The main routes to building an app are:
| Build route | Indicative first-version cost (UK, 2026) | What you get |
|---|---|---|
| AI prompt-to-app builder (e.g. Base44 or Replit) | £0 to £2,000 plus subscriptions | A working web app but one that likely has a lot of holes in it; app store presence only via a wrapper |
| No-code platform | £3,000 to £30,000 | Agency-built, or platform fees plus your own time. An app inside the platform's limits, usually priced per user and often with gaps in the solution |
| Wrapped web app or PWA | £10,000 to £40,000 | Where a web product already exists. Store presence for web technology |
| Cross-platform frameworks e.g. Flutter (created by Google), .NET MAUI (Microsoft), and React Native (Meta) | £30,000 to £120,000 | One codebase producing real iOS and Android apps |
| OS vendor frameworks. Swift (Apple), Kotlin (Google) | £80,000 to £250,000+ | Maximum capability and performance, two codebases |
It's worth noting that very few businesses have to use OS vendor frameworks, almost all apps are well served with cross-platform frameworks.
The ranges in this guide are indicative for the UK market, based on published rate data and our experience scoping and delivering mobile app development projects. The ranges are wide because costs vary widely depending on the project. Throughout the rest of this guide we will provide the information you need to narrow down this range for your app.
Why the range is so wide
Two apps can look identical in a screenshot and differ in cost by a factor of more than ten. The label "fitness app" or "marketplace app" tells you very little. The biggest driver is scope: how many features the app has, and how deep each one goes.
The feature count is the obvious half. Feature depth is the half that catches people out, because the same feature name can describe two very different builds. Take "tournament creation and management" in a sports club app as an example. That could mean something relatively simple like:
- an admin creating a tournament
- adding the name, date, venue and player list
- creating a basic bracket or fixture list manually
- members viewing tournament information and results
- admins updating winners manually
Or it could mean a much more advanced version of the same feature such as:
- different tournament formats such as knockout, round robin and group stages
- automatic draw generation and seeding
- match scheduling across multiple courts and time slots
- live score entry with automatic progression of winners
- handling withdrawals, substitutions, rescheduling and delays
- push notifications to players
- coach and club visibility rules
- historical stats, rankings and reports
- multi-city, multi-club permissions and access control
On paper, both sit under the label "tournament management", but the advanced version could easily cost five times more than the simpler one, sometimes more. Most products contain tens of features with this kind of hidden range inside them, which is why two quotes for "the same app" can sit so far apart unless proper analysis has been done.
Beyond scope, the cost of an app sits in a handful of underlying characteristics:
- How deep the app goes into the device. Camera pipelines, Bluetooth hardware, background location and offline sync may demand native engineering. Ordinary screens and forms don't.
- The richness of the interaction. Gesture-driven, animated interfaces cost multiples of tap-and-scroll ones, in both design and build.
- The weight of the backend. A large share of "app" cost has little to do with the app itself: servers, databases, APIs, admin tools and the integrations behind them drive cost. A well-documented payment API might be a day's work; a fifteen-year-old internal system with no documentation is a much more expensive exercise.
- Regulation. Industries such as health, finance and gambling carry compliance, audit and security obligations that can push budgets up.
- Scale. Software for 5 internal users and software for 200,000 consumers are different disciplines.
- Distribution. Plenty of "apps" are better served by an installable web app, at a fraction of the cost, with no app store involved.
Named app types are just bundles of these characteristics. A fitness app that shows workout videos is a content app. A fitness app that analyses your squat form through the camera is a computer-vision product. Same shelf in the store, different order of engineering. So when you brief anyone on your project, describe the features, their depth, and the characteristics above to get more accurate cost guidance.
The five primary ways to build an app, and what each costs
AI prompt-to-app builders
Tools like Base44, Lovable and Bolt turn a written description into a working application for the price of a subscription. All three have free tiers that are enough to experiment with. Paid plans start at roughly $20 to $25 a month, and because every one of them meters usage in credits or tokens, a month of serious building usually lands on the heavier tiers: Base44's run up to $200 a month, and Bolt's token top-ups can push well past that.
Two things to know. First, most of them build web apps; their route to the app stores is wrapping that web app in a native shell, which Apple sometimes rejects and users can usually feel. A newer group of tools generates genuine React Native projects instead. Second, nobody yet has good evidence on how maintainable these generated codebases are once a product succeeds and needs changes over time. For testing an idea or running an internal tool, they can be excellent value. For a serious business app, and certainly anything business-critical, they are probably either not suitable, or are just for creating prototypes.
No-code and low-code platforms
Visual builders like Glide and Bubble get you to a working product without engineers. FlutterFlow sits at the serious end, generating Flutter code you can export and keep. The real costs arrive later with per-user pricing that scales with success, and a capability ceiling that eventually forces a decision to rebuild. When you outgrow the platform, the exit is usually a rebuild.
Note: Without a knowledgeable development firm engineering either of the two routes above, serious risk is introduced. The tools described can often produce impressive-looking products but if the people that built the app don't understand what's happening under the hood, huge risk is introduced.
A wrapped web app or PWA
If you already have a web product, tools like Capacitor put it inside a native shell and into the app stores for a fraction of the cost of a new build. A progressive web app skips the stores entirely and installs from the browser. Both are legitimate. Both show their seams in interaction-heavy products, and Apple's review team rejects apps that are obviously just websites in a box.
It's worth drawing a line here. Everything so far gets you an app by prompting, configuring or wrapping: mostly web technology under the surface, which is exactly why those routes are cheap. From this point on you're commissioning purpose-built software, designed and engineered for the phone, installed and running natively on it. This is where most people's idea of "a real app" begins, and where the budget shifts from subscriptions and weeks to teams and months.
Cross-platform frameworks
Flutter, .NET MAUI, and React Native produce installable iOS and Android apps from one codebase, and they're the default for most new commercial builds for a reason: you get most of native capability, well under the cost of building everything twice. Some budget still goes to platform-specific quirks, but it's a much lower cost way of launching and maintaining native apps.
Fully native
Swift for iOS, Kotlin for Android. Two codebases, full access to everything the platforms can do, and the highest cost on this page. You should choose it when the platform capability is the product e.g. serious camera work, AR, hardware integration, watch-first experiences, not as a default.
One pattern to keep in mind across all five options: the cheap routes mostly defer cost rather than remove it. A no-code build that succeeds, usually gets rebuilt. An AI-generated app that finds its market gets re-engineered. That can be fine, paying £3,000 now and £80,000 later, only if the idea works, can be a valid strategy. Just budget with your eyes open.
What actually drives mobile app development cost?
This is broken into three categories: factors you control, factors you only partly control, and factors outside your control.
Factors in your control
Scope is the biggest single lever anyone controls: the number of features, screens, user roles and the business logic behind them. Then platform strategy (one platform, two, or web), design ambition (standard components versus bespoke motion design), the build route and supplier covered either side of this section, and timeline. On that last one, compressing a fixed scope adds cost, because parallel work brings coordination overhead.
Factors you only partly control
Requirements stability comes first: change mid-build is the great budget multiplier, and a well-specified app reliably costs less than a vaguely specified one of the same size. Then integrations, where the effort depends on systems outside anyone's control and often can't be judged until access is granted. And QA depth, but be careful because if you cut testing too much, the cost simply moves to post-launch, with interest.
Factors outside of your control
Regulation in your sector, the app stores' rules and fees, and what users do at launch, which sets the iteration bill.
App development cost by stage
Everything above talks about the cost of the whole journey but app development happens in stages. These stages can be manipulated to minimise your budget.
Stage 1: Discovery £5,000 – £10,000
Discovery establishes what the app is for: who'll use it, what they do today, what the business needs it to change, which systems it has to talk to, and where the risk and uncertainty sits. This typically involves stakeholder workshops, user research, a review of the systems and data involved, and sometimes a technical spike on the genuinely uncertain parts.
Done properly, Discovery protects you against building the wrong thing. Done as a sales ritual, it's theatre that sets your project up for failure.
Stage 2: Scoping £6,000 – £20,000
Scoping turns the direction identified in Discovery into something a team can accurately price and build. The feature list gets settled, and so does the depth of each feature, which is where a lot of the cost is determined: the tournament example earlier is a scoping decision. So are the build route, the technical architecture, the integration detail, the delivery plan, and a costed estimate with its assumptions written down. It's often at this stage that fixed price quotes can be given.
On smaller projects, discovery and scoping are often sold as a single engagement. That's fine. What matters is that both jobs get done, whatever the phase is called. The important thing to assess is whether without Discovery, you know enough about the supplier to trust them with the build of your app.
What you're buying: a specification suppliers can price like-for-like, which is the only thing that makes competing quotes comparable.
Stage 3: Build £25,000 – £150,000+
Keeping the build budget to a minimum usually involves building the smallest version that tests your assumptions. The first release might be one core workflow done really well, or it could be a web app rather than a native mobile app.
Stage 4: Launch and first iterations
Launch can take longer than the word suggests: store submission and review, a closed beta (Google requires new individual developer accounts to run a closed test with a minimum number of testers for two weeks before production access, which ambushes plenty of first launches), analytics setup before release because day-one data can't be retrofitted, and a first round of changes driven by how people use the app.
Stage 5: Running your app 10 – 20% of build cost per year
That percentage is a rule of thumb but it covers items such as OS updates that break things, security patches, store policy changes, third-party APIs that get deprecated or repriced, hosting that scales with success, and the improvements users ask for. An app that isn't maintained degrades. Skip this investment and you usually won't get the returns from your app that you're hoping for.
Who builds your app changes the cost
There are, broadly speaking, 5 categories of supplier that can deliver a mobile app project. The same project will be quoted at wildly different prices depending who you ask.
| Supplier type | Indicative UK day rate (2026) | Best suited to |
|---|---|---|
| Freelancer (UK) | £250 to £600 | Narrow, well-specified work; prototypes; augmenting a team |
| Offshore or nearshore team | £120 to £700 | Cost-sensitive builds where you have software development expertise and can supply direction and QA. Augmenting existing capability. |
| Micro agency (2 to 15 people) | £350 to £600 | Less complex projects for startups and SMEs. |
| Full-service app development agency | £550 to £1,000 | Full builds needing design, engineering, QA and management under one roof. Often the minimum viable choice if your project involves more than 'just mobile', for example complex integrations, backend development etc. |
| Blue-chip agency | £1,000 to £1,600 | Household-name brands and flagship consumer products, where design pedigree and the agency's name are part of what's being bought |
Day rate and total cost aren't the same thing. A cheaper day rate becomes a cheaper project only if delivery speed, quality, rework and management overhead hold steady, and they usually don't. The gap between the two comes down to whether every discipline the project needs is covered, the experience and quality of the team, who carries the management burden, and what happens when something goes wrong.
Discipline coverage is an important point because a production app is not one skill. A typical build draws on product management, UX and UI design, front-end and back-end engineering, technical leadership, QA and delivery management. Freelancers, offshore teams and smaller micro agencies often don't have all these specialist capabilities. It's often hard to tell this from a proposal because the gaps surface later, as rework, missed requirements and defects in production show up.
Offshore savings can be real when the buyer supplies direction and quality control, but "the buyer" in that sentence means an experienced product and engineering function of your own: people who can judge an architecture, challenge a design, prioritise a backlog and test properly. Direction is a specialised job in its own right, and if you don't have deep expertise doing this yourself, a low day rate can transfer one of the hardest roles on the project to one of the least qualified people on it.
Watch, too, for partners whose core skill is not full system design, build and maintenance. The classic version is the design agency that produces beautiful mockups and wireframes but outsources the development; the mirror image is the dev shop that builds exactly what was asked, never questioning whether it's the right thing to do. Building the right thing is a rigorous, structured process of understanding and prioritising requirements, shaping a product architecture and sequencing a roadmap, and that's a different skillset from visual design and from raw engineering.
At the top of the table, blue-chip and consultancy rates buy pedigree, procurement comfort and integration muscle that most projects below enterprise scale don't need.
The important point to take away from the table above is not to over or under buy. A medium-sized and above business that wants to launch a production app, probably shouldn't use a freelancer. Equally, spending on a blue chip agency would likely be a waste of budget.
How to get an accurate quote that you can trust
The only way to get an accurate quote is for work to start (even if that is a free engagement initially). The further you go down the solution design process, the more certainty you have around costs.
In order to give accurate budget guidance, a partner would need to understand factors such as:
- The high-level modules or epics, and the features inside them
- The systems the app needs to integrate with
- Who the app serves, and how they currently work
- Scale, both users and data
- Security and compliance obligations
- Technical constraints
- The business goals, which guide core decisions around things such as platform strategy, build route and architecture
Only with all of that can a supplier make a judgement on the best approach, then on the work that approach requires, then on the budget. When you skip any of this, you are introducing uncertainty into the quote.
The process to get this level of detail is usually Discovery. Typical market rates are around £5,000. At Steer73, we typically offer Discovery for free because it is such an important stage in setting the project up for success.
If you can't run Discovery, then the quotes that have gone the furthest to understanding the above are the ones likely to produce the most accurate cost guidance.
It's worth noting that getting accurate cost estimates is not about finding the firm that produces the best looking screen mockups.
15 questions to ask a potential development partner
Once you have proposals from potential partners, we recommend asking the following questions to give you insights into the level of certainty you can have around the costs that have been shared.
Which disciplines do you have in-house, and which do you subcontract?
Product management, UX, UI, front end, back end, technical leadership, QA and delivery management. Design agencies that outsource engineering and dev shops that outsource design both exist, and both produce a proposal that looks fine but can cause issues down the line, including costly rework.
Who owns the code, the designs and the Discovery output?
Accounts registered in the agency's name are a common trap and an avoidable one. If you want to run Discovery with one firm and tender the build to others, this is the question that determines whether you can.
What are the running costs, and what is likely to break if we do nothing for a year?
Tests whether they've maintained products or just built them. A supplier who talks fluently about OS releases, deprecated APIs, store policy changes and hosting that scales with usage has been there. One who brushes over the topic probably hasn't.
Show me the epic and feature breakdown, and how the estimate maps onto it.
Real analysis produces a structure: modules or epics, features underneath, a number against each. Check the parts reconcile to the headline figure. If every line lands on a neat round number, the breakdown could have been apportioned backwards from a price they'd already decided.
How many features are on the list, and how did you arrive at that number?
Unglamorous, and it separates people quickly. Anyone who has decomposed your app knows roughly how many features it holds, because they counted them. Ask which epic turned out to hold the most, and whether that surprised them.
Which features have you classified as simple, standard or complex, and why?
The reasoning matters more than the labels. You want to hear something attached to each: complex because of the offline sync, standard because it's forms and a list view, simple but sitting behind an integration nobody has seen yet.
What have you taken out?
Analysis is subtractive as well as additive. A supplier who has genuinely thought about your app has usually decided that some of it belongs in a later phase or shouldn't be built. Ask what they'd cut from the first release and what that saves. If nothing has been cut, the feature list was priced rather than examined.
What do you think the technical architecture looks like, and why?
Ask things such as which build route would you recommend, what the backend looks like, where the risk sits. If they can talk through a diagram, design work has happened. If the answer is that they'd decide it during Discovery, that's a legitimate answer, but then the price they've given you isn't firm and they should be willing to say so.
What user roles and permissions have you identified?
Roles add scope, and they're a good proxy for whether anyone traced the app through to its edges. Working from a brief alone, most suppliers spot the obvious two. One that has thought it through properly may come back with the admin, the support user, the read-only observer, and a question about who is allowed to delete things.
Which integration did you look at hardest, and what did you find?
Then ask what they actually did: read the documentation, called the vendor, wrote a test against the API. There's a real difference between noting that an integration exists and checking whether it does what you need, and the second produces a specific finding. Again, you might need to be realistic about how much time a partner can spend on this investigation given the stage you're in, but integrations can add a lot of cost, so the level of uncertainty against budgets should be understood.
What don't you know yet, and what would you need to do to find out?
This could be access to a system, a conversation with whoever owns the legacy database, or sight of the API documentation. A supplier with no open questions is either not looking or not telling you.
What would you want to understand better before committing to a fixed price?
Related to the above but sharper, because it asks them to name the things that could move the cost of your app. Specific unknowns with reasons and rough times against them is evidence of engineering judgement applied to your project rather than guesswork.
Show me the assumptions register.
Vague assumptions mean the work hasn't been examined.
Show me the exclusions.
This may include QA depth, device coverage, store submission, documentation, third-party licences, penetration testing, support after launch. A cheap quote is often a normal quote with a longer exclusions list.
Where does this estimate go up, what are the three biggest risks, and what is each one worth?
This question should help you assess the team's understanding of your project, as well as the areas that you need to keep an eye on to ensure budgets don't creep up.
If a supplier can't produce most of this, that isn't necessarily a reason to walk away. It may just mean they haven't done the work yet, which is fair enough if you haven't hired them yet. What it does mean is that the number they've given you is a guess, and it should be treated as one until the analysis behind it exists.
Frequently asked questions
How much does it cost to build an app like Uber, JustPark, AirBnB etc?
The question hides a trap: These are apps with decades of engineering by thousands of people, and nobody is quoting you for that. What people usually mean is something like "an on-demand marketplace with booking, payments and tracking, and a credible regional first version of that runs £60,000 to £150,000." That can be quoted for but don't make the mistake of thinking popular apps can be easily copied.
How much does an MVP cost in the UK?
A single-purpose first version of an app typically costs between £25,000 to £75,000.
How much does app maintenance cost per year?
Plan for 10 to 20% of the original build cost annually. It's a rule of thumb, but the costs underneath it are real: OS updates, security patches, store policy changes, API changes, hosting and improvements. Zero-maintenance budgets produce degrading apps.
Is it cheaper to build an app with AI or no-code tools?
Upfront, dramatically so: hundreds of pounds instead of tens of thousands. Over a product's life, it's less clear. Per-user platform pricing, capability ceilings and the eventual rebuild are all costs that are probably going to come up in the future. For validating an idea or running a simple internal tool, they can be the right call, for a "serious" app, a cross-platform app written in something like Flutter, is a more established choice.
Does iOS or Android cost more to build for?
Per platform, costs are broadly similar. The real question is whether you should be building two separate code bases at all: building both natively is often unnecessarily expensive, and cross-platform frameworks reduce the cost significantly.
How long does app development take?
Discovery takes two to six weeks. A mid-scope first version often takes three to six months. After that it stops being a project with an end date and becomes a product with a roadmap.