What things cost 15 min read

How Much Does App Development Cost in the UK?

Real UK app development costs: price ranges by app type, what drives the budget, how AI-accelerated delivery changes the number, and what a quote should cover.

How much does app development cost in the UK? Code23’s published price for a custom MVP or web app is £18,000-£40,000, typically built in 6 to 10 weeks, with user accounts, roles, Stripe billing, dashboards, automated tests and a 90-day warranty. Native iOS and Android builds, real-time features and regulated products cost more, and we price those once they’re scoped. If your brief isn’t clear enough to price yet, a Discovery Sprint turns it into a fixed build price first. Store fees, maintenance and hosting sit on top, and that’s where thin quotes go to die. Once we’ve scoped your app properly, we set one fixed price for it, with any changes priced before we do them.

The short answer: UK app costs by type

TypeHow we price itWhat you’re usually buying
PWA / installable web appWithin our published custom MVP / web app priceApp-like UX in the browser; offline where needed; no store gatekeepers
Simple MVP (one platform)Within our published custom MVP / web app price as a web app; native quoted once scopedFew core screens, basic auth, thin backend, learn-fast scope
Cross-platform consumer / SMEFixed price once scopediOS + Android from one codebase; accounts; payments or 1-2 integrations
Native (single platform)Fixed price once scopedSwift or Kotlin depth; hardware-heavy features
Native both platformsFixed price once scoped; two codebases cost more than oneTwo codebases, two test surfaces, two release trains
Complex / regulatedFixed price once scoped, usually after a Discovery SprintMulti-role, real-time, compliance, heavy admin

AI-accelerated delivery changes the economics on the parts of a build that compress well, covered below. Sibling cost pieces: website development cost UK, SaaS development cost, and timing context in MVP build time. Hub: websites and apps.

UK agency vs offshore vs freelancer economics

UK agencies may charge more per hour; compare what discovery, design, assurance and warranty are included.

Offshore teams can lower rates, but evaluate timezone, communication and product ownership for the actual team.

Freelancers can suit narrow scopes; broader apps need design, backend, store operations and support covered somewhere.

Blended teams exist. Price the communication overhead explicitly. Agree the price and change-control process before work starts; that keeps scope changes explicit and reduces the chance of arguments later, whatever team shape you hire.

What drives the budget

Screens and flows. Ten polished screens with edge cases beat forty empty shells. Count states, not just Figma frames: logged-out, empty, error, pending, admin override.

Auth and roles. Magic link for one role is cheap. Organisations, invites, permissions matrices and audit trails are product work. Marketplace-style multi-sided apps draw on what we’ve learned building 50+ marketplaces over 15+ years.

Payments. On iOS, digital content and subscriptions sold inside the app generally have to use Apple’s in-app purchase, while physical goods and services used outside the app must use another method, such as card payments through Stripe. Marketplace-style payouts to sellers need something like Stripe Connect. Payment choice reshapes onboarding. Decide it early, before design work starts.

Offline and device APIs. Background location, Bluetooth, heavy camera processing, secure storage. This is where native earns its keep - and where estimates go soft if you pretend every feature is a web view.

Integrations and backend. CRM, ERP, inventory, notification providers. Each trustworthy integration needs failure modes, not only a happy-path demo.

Design and accessibility. Custom motion and dense B2B UI cost more than a template skin. Accessibility is part of the build, not a nice-to-have slide.

Compliance. Fintech, health, children’s data - budget for process, not only code. If you need regulated claims, say so before anyone prices a “simple app”.

DriverLean MVPProduction SMEComplex
Screens5-10 core12-2525+ with admin
AuthSingle roleRoles + orgFine-grained + audit
PaymentsNone or simpleCard / subsPayouts, multi-party
OfflineMinimalSelectiveFirst-class
Integrations0-12-4Many + sync
Three OI Flow app screens: a pre-shift vehicle check with tyres, damage, fluids and warning lights confirmed, today's job list with a start-shift button, and a task list showing one of three jobs complete
OI Flow, the field app we designed for a property maintenance contractor: vehicle checks, today's jobs and task lists, built for one-handed use on site.

Web app, PWA or native: pay for what your users actually need

Web app. A web app can be a fast route when desktop matters and installation is optional. Weak when you need store discovery or deep device APIs.

PWA. Installable, offline-capable enough for many field and content use cases, no store cut. Strong when your users will open a URL. Weak when you rely on push notifications, since iPhone users only get them after adding the web app to their Home Screen, or when you need store presence for distribution.

Cross-platform (Flutter / React Native and peers). Cross-platform frameworks let teams share much of one codebase across iOS and Android. They can reduce duplicated work, but suitability and cost depend on device APIs, performance and release requirements.

Native. When performance, platform UI fidelity or device APIs are the product. You pay for two platforms if you need both.

A rule from building 50+ marketplaces over 15+ years: distribution and liquidity problems are rarely solved by choosing native for its own prestige. Pick the thinnest client that supports the transaction loop you must run in month one. Evolve the client when usage data says you must - not when a vendor prefers a stack.

A second rule: admin isn’t optional polish. If your team can’t pause a user, refund a payment or edit a listing without a deploy, you built a liability. Price admin into v1 whenever money or trust is on the line - the same lesson we learned shipping platforms with real money flows.

Three OI Flow app screens: a pre-work site safety checklist, a task screen requiring a photo before it can be finished, and a finish-task screen asking whether the job is complete
The same app: a safety checklist, photo evidence required on a task, and a finish-task question. It was designed to work with gloves on and in basements with no signal, and device needs like these decide how far past a basic web app a build has to go.

Running costs after launch

Build invoices are the entry fee. Running costs are the membership. Founders who only fund the build often find this out in month two, on an OS release or a payment edge case.

Stores. Apple’s developer programme costs $99 a year and Google Play charges a one-off $25 registration fee, before review cycles, compliance questionnaires and each store’s percentage on in-app purchases where it applies.

Hosting and backends. APIs, databases, file storage, push providers, observability. Quiet until traffic or a bad release.

Maintenance. OS releases can break things. Dependency updates aren’t optional. Budget real engineer time. Our published support tiers at £495 / £1,850 / £3,450 a month cover the web platform and backend behind an app; store releases and OS update work are scoped with you, because “we’ll call someone when it breaks” isn’t a strategy. What each tier includes, and how extra work is charged, is set out on our pricing page.

Support load. Password resets and payment edge cases. Software doesn’t answer Slack; people or a tier does.

Iteration. The first app that earns money earns a backlog. If you can only fund v1, you can’t fund the product.

We constantly see founders under-budget running costs - the same pattern we see with operational costs on marketplace platforms we help launch. If the app touches payments or multi-sided users, ops cost follows trust, not UI polish. Price a quiet month of monitoring and a noisy month of support before you celebrate the build invoice.

MVP scope that keeps the bill honest

An MVP isn’t “half the features with the same ambition”. It’s the smallest product that completes one valuable loop.

Good MVP cuts:

  • One primary role first (add the second role when the first loop works)
  • One platform if distribution allows (prove demand before dual native)
  • Manual ops behind the curtain for rare edge cases
  • Analytics on the loop you claim to care about

Bad MVP cuts:

  • Skipping auth “for now” on a multi-user product
  • Skipping admin so every change needs a developer
  • Skipping security and accessibility testing so store rejection becomes the QA department
  • Shipping seven half-flows instead of one complete flow

We’ve built 50+ marketplaces over 15+ years, lean and full platforms alike, and the pattern transfers to apps. Liquidity and usage teach you what to build next. A fat v1 teaches you how to spend money.

Timeline orientation for lean scopes sits in MVP build time. Cost for adjacent SaaS and product shapes is in SaaS development cost.

[ the mvp cut ] Cut features, preserve the value loop and required controls
Working rule Preserve the value loop and any safety, authentication and admin controls the release needs
01KeepOne role, one platform where you can, the loop that proves value
02CutExtra personas, edge-case billing, features nobody asked for
03ProtectSafety, compliance, accessibility, authentication, admin and the flow you're testing
Bad MVPs cut the wrong things. Good MVPs preserve the value loop and any safety, authentication and admin controls the release needs.

What a serious app quote includes

Demand these lines on paper:

  • Platforms and languages / frameworks
  • Screen and role inventory
  • Offline and device API list
  • Payment approach and who holds merchant accounts
  • Backend ownership (included vs client-provided)
  • Admin / CMS requirements
  • Analytics and crash reporting
  • Accessibility target
  • Test approach and store submission ownership
  • Environments (dev / staging / production)
  • Warranty and support path after launch
  • Assumed client-supplied assets and dates
  • Hourly rate for extras

A large price difference may mean the quotes cover different scopes, so check which of those lines is missing. Agreeing the fixed price before we start helps prevent silent scope expansion; the 90-day warranty covers defects within spec. Our published support retainers cover the web platform and backend, while store releases and OS-update work are scoped separately.

How AI-accelerated delivery changes app economics

Agents compress implementation when the design system and API contracts are clear: screens, tests, refactors, boilerplate. They don’t compress unclear product decisions, App Store politics, or a missing backend owner.

What changes in our builds:

  • Faster first passes on UI and test scaffolding
  • Quicker refactors when a flow shifts mid-project
  • More options explored before a human locks direction
  • Faster throughput on the parts of a build that compress well, which lowers the cost of comparable work (method: build-time data)

What doesn’t change:

  • Need for human release authority
  • Security and accessibility testing before store submission
  • Payment and permission design
  • Running costs after launch

How we price project work: a fixed price agreed before build starts; payments staged against agreed milestones, with the split set out in the proposal; a 90-day warranty on defects within spec; then a support retainer if you want continuous feature delivery or ongoing security cover. That accountability model predates agents - since 2005 and across 350+ projects. Using AI well means senior people directing the agents, not unsupervised store releases.

Across 350+ projects since 2005, we’ve found unclear quotes create overrun arguments. Clear scopes reduce overrun disputes and make changes easier to price.

Apps earn their keep when the commercial loop is real and the run budget exists. The build line is only the first cheque. Choose the thinnest client that serves month-one users, price security testing and store submission in the open, and treat maintenance as part of ownership rather than an awkward surprise after launch week. Apps are no different - launch is the start of ops, not the end of spend.

An app quote is usable when platforms, roles, payments, security testing and month-one run cost are on the same page. Price that shape via websites and apps.

Frequently asked questions

How much does it cost to create an app in the UK?

It depends on the platforms, roles, payments and integrations. We publish a fixed price for a custom MVP or web app; native, real-time and regulated apps cost more and we price them once they’re scoped.

Is it expensive to develop an app?

It is expensive compared with a marketing site. Compare the investment with the value and risk of the problem - expense tracks scope, platform choice and assurance, not the word “app” itself.

Is owning an app profitable?

It can be, when the app sits on a real revenue loop (transactions, subscriptions, retained internal efficiency) and you fund operations. Software without a commercial loop is a cost centre.

How much is an app with 100,000 users worth?

There’s no universal price; valuation follows revenue, retention, margins and risk, not raw installs - 100,000 empty accounts can be worth near zero, while a smaller base with strong paying retention can be worth a serious multiple.

How much does it cost to run an app after launch?

Hosting, app store fees, third-party APIs and ongoing maintenance add up to a real monthly cost, not a one-off. Our retainers cover the web platform and backend’s hosting, monitoring and security; store releases, OS-update work, store fees and APIs are scoped separately.

Is Code23 good value for app development?

We don’t compete on being the cheapest quote. We compete on a fixed price agreed before we start, no silent scope expansion once work begins, and 350+ projects delivered since 2005. Value in an app quote shows up in what it includes and excludes, not just the number on the page.

Is a web app cheaper than a native app?

Usually, yes. A web app or PWA needs no store approval and often costs less to build and maintain than an equivalent native app, especially when people just open a URL. Native earns its extra cost when performance, platform feel or deep device features such as Bluetooth, background location or heavy camera processing are the actual product, not a nice-to-have.

Sources

Next step

A cheap app quote that skips admin, security work or month-one running costs is only cheaper on paper. It’s a smaller job wearing the same label.

We’ve delivered 350+ projects since 2005, including platforms with admin, payments and support built in from the start, not bolted on after launch. If your brief is already clear, we’ll turn it into a fixed price directly. If it isn’t yet, our Discovery Sprint gets you an interactive prototype, the system architecture and a fixed-price build proposal in one to two weeks, at £750-£1,500, credited in full against the build if you go ahead.

Get cost certainty

Get a fixed price before the build starts.

We’ll discuss what you need, then get back to you with a clear price and timescale within 48 hours.

James Ansell

Written by

James Ansell

Founder & Director

James founded Code23 in 2005 and leads its AI, product and engineering work across marketplaces, SaaS platforms and websites.

Related

More from the blog

Engineering deep-dives, product updates, and notes from the team.

View all posts