How much does it cost to build an app?

The short answer

There is no price for "an app", and any supplier who gives you one from a sentence is guessing. The cost is set by scope — how many types of user, how many systems it talks to, how many platforms it runs on — and those vary so widely that the same one-line idea can honestly be a £10,000 project or a £200,000 one.

What we can give you is a floor. Our quote page says it plainly: apps and portals are software projects that often take hundreds of hours to design and develop, so building something bespoke for under £7.5k is unlikely. It is possible with very simple requirements, but most of our projects are more than that.

This guide explains which decisions change an app development budget, how to compare estimates and what to allow for after launch. For the steps to getting a project-specific estimate, visit our app development cost and quote page.

Why nobody can price an app from a description

Two people describing "a booking app" can mean projects an order of magnitude apart. One means a single-screen form that emails the office. The other means multi-site availability, staff rotas, deposits, refunds, calendar sync, a customer app, an admin portal and a rules engine for cancellation policies.

Both descriptions are honest. The difference only appears when someone asks the second-order questions, which is what a scoping engagement is for. Until those answers exist, an estimate is a bet on which interpretation you meant, and suppliers manage that bet in one of two ways: quote high to be safe, or quote low and recover the difference through change requests. Neither serves you.

This is why we treat planning as a separate, fixed-price piece of work rather than something absorbed into a sales conversation. Quickstart App Planning typically completes within 3 to 6 weeks and produces the scope and estimate you then build against.

The five things that actually drive the price

In our experience almost all the variation between two quotes for "the same" app traces to these five, in roughly this order of impact:

1. How many distinct user types. One user type is straightforward. Five, with a permission hierarchy between them — head office, regional manager, site user, contractor, customer — is a different project. Permissions multiply the testing surface more than any other single decision.
2. How many integrations, and how good the other end is. Connecting to a modern product with a documented API is routine. Connecting to a legacy system with no API, or one whose data is inconsistent, can cost more than the app.
3. How many platforms. A web app is one build. Web plus iOS plus Android can approach three, depending on the technology chosen. Ask whether you genuinely need native apps or whether a web app on a phone does the job.
4. Whether it must work offline. Offline capability means the app has to hold its own copy of the data and reconcile conflicts later. It is one of the most consistently underestimated requirements in briefs we receive.
5. How much of it is bespoke logic versus standard screens. Lists, forms and dashboards are quick. A pricing engine, a scheduling optimiser or a compliance rules engine is where the hours go.

Compare three scopes before comparing prices

These are illustrative scope comparisons, not packages or price promises. Each starts with the same idea: let customers book a service. The differences explain why a useful quote needs more than a feature name.

A focused web booking MVP

One customer type chooses a service, requests a time and receives a confirmation. Staff approve bookings in a small administration area. Availability can be maintained manually while the business tests demand. Ask the supplier to identify the design, administration, testing and launch work included in the estimate.

A connected customer portal

Customers see live availability, manage bookings and view account history. Staff permissions, payment handling, refunds and a connection to the existing business system extend the work. The quote needs assumptions about the external API, duplicate records, failed payments and who resolves exceptions.

A mobile service platform

Customers use iOS and Android apps; staff may need offline access, notifications, location features or different permissions. The budget must include device testing, synchronisation rules, store submission and ongoing platform updates. Shared code can reduce duplicated development, but does not remove platform-specific testing.

Choose the smallest scope that can test the intended outcome. Ask for optional features to be itemised separately so that a supplier's estimate becomes a decision you can make, rather than a number you can only accept or reject.

Compare app development quotes on the same basis

Before comparing totals, ask each supplier to confirm these items in writing:

• Scope: the user journeys, user roles, platforms and administration tools included, with clear exclusions.
• Assumptions: data quality, access to existing systems, API availability and any decisions still unresolved.
• Delivery: whether the figure is an early estimate, a fixed scope quote or a budget for a sequence of sprints.
• Quality and launch: design review, security, accessibility needs, testing, data migration and deployment responsibilities.
• Commercial terms: VAT treatment, third-party charges, payment milestones, change approval and code ownership.
• Running costs: hosting, support, monitoring, backups, licences and usage-based services, including the usage assumptions.
• Handover: documentation, access to accounts, maintenance responsibility and how a future supplier could take over.

Keep a separate line for uncertain work. For example, if an integration has not been investigated, agree how it will be assessed and when the estimate will be revised. A contingency is a planning allowance, not permission to spend without approval.

Complexity inside a feature, not the length of the feature list

Counting features is the most common way to size an app and the least reliable one. Most of the variation lives inside each feature rather than in how many there are.

Take user accounts. The simple version stores an email address and a securely hashed password and has a registration form. The involved version adds Apple, Google and Facebook sign-in, two-factor authentication, a multi-step onboarding flow that collects extra information, an editable profile, and a completeness score that nudges people to finish it. Both are honestly described as "user accounts", and the second can take ten times as long to build and test as the first.

So a brief listing twenty features tells a supplier less than one describing three of them properly. When two quotes differ, check what each one assumed a feature meant before concluding that one supplier is expensive.

Prototype, MVP or mature product: three different budgets

"An app" covers three quite different pieces of work, and confusing them is why estimates sometimes land nowhere near expectation.

• A clickable prototype is design only. Real screens and real navigation, with nothing engineered behind them — enough to put in front of users, show a board or an investor, and settle arguments about scope before anybody writes code. It is by a wide margin the cheapest of the three.
• An MVP is working software, narrowed to the smallest thing that does a real job for a real user. It is built properly — accounts, security, hosting and testing are not the parts you skip — but it deliberately serves one user type doing one job. Our sprint-based delivery, Velocity Sprints, aims to launch a usable MVP within two to eight weeks, typically across two to four sprints, with one sprint committed at a time.
• A mature product is what an MVP becomes after real use: more user types, more integrations, reporting, admin tooling, edge cases and the steady stream of changes that usage generates. Most of the lifetime cost of a successful app sits here, not in the first release.

If you are still deciding whether the idea is worth building at all, an idea validation package tests that before you commit a build budget. If the idea is sound but its contents are not settled, planning and design is the cheaper place to make those decisions.

What sits behind the screens

Four cost centres rarely appear in a brief, because none of them is visible in the finished app.

• Platform choice. A web app is one build; adding iOS and Android can approach three, depending on the technology. Cross-platform frameworks bring that down considerably, which is why most of our mobile app work is built once and released to both stores. Decide whether you genuinely need a store presence or whether a web app on a phone does the job.
• Design. Screens are designed before they are built, and that cost scales with the number of distinct screens and states, not with how polished it looks.
• The back end. Users see the app; a good share of the cost sits behind it — the data model, the admin tooling somebody needs in order to run the thing day to day, reporting, and the infrastructure it all sits on.
• Compliance. If the app handles personal data, UK GDPR applies and data protection has to be designed in rather than bolted on. Taking card payments means using a provider that carries the PCI burden for you. Public sector work brings accessibility obligations. Each of these can be routine when known up front and expensive to retrofit, so put them in the brief rather than discovering them in testing.

How suppliers charge

Three models dominate, and the pricing model changes your risk more than it changes your total.

• Fixed price, as in our fixed-fee delivery. You get one agreed figure for an agreed scope. Watch out: every change becomes a change request, and it requires the scope to be genuinely settled first, so it follows a paid planning phase.
• Fixed-price sprints, as in our Velocity Sprints. You get a fixed cost per sprint, with scope agreed sprint by sprint. Watch out: you need to stay involved, and the total is deliberately not fixed at the start.
• Day rate, or time and materials. You get maximum flexibility. Watch out: there is no cost ceiling. Sensible for genuinely open-ended work, risky for a defined first build.

In our projects, sprint-based delivery is a fixed price per sprint with a predictable number of Output Units — units of finished work rather than hours spent. Most clients start with 2 to 4 sprints, commit one at a time, and can stop at the end of the current sprint. For fixed-scope programmes, we typically recommend delivering a brand-new project within three to six months; beyond six months, our experience is that too many requirements have been packed into one release.

Payment normally tracks delivery rather than arriving as a single invoice. The worked example on our quote page is a £20,000 project running three months, split into four payments: a deposit, then one at the end of each month.

The costs that are not the build

A first quote covers building the thing. These continue afterwards, and leaving them out of the business case is the most common budgeting mistake we see.

• Hosting and infrastructure, monthly, scaling with usage.
• App store fees, if you are publishing mobile apps. The Apple Developer Program is a $99 annual membership and Google Play charges a US$25 one-time registration fee.
• Third-party services — payment processing, SMS, mapping, email delivery, and any AI model usage, all typically per-transaction.
• Maintenance. Operating systems, browsers and dependencies move underneath you. An app left untouched for two years is not stable, it is out of date, and store review requirements change too — Apple updates its App Review Guidelines regularly.
• The next round of changes. Every app that gets used generates requests. Budget for ongoing support or accept that it will stand still.

How to spend less without regretting it

There are good and bad ways to reduce the number. The good ones all involve reducing scope before the build rather than reducing quality during it.

Narrow the first release. One user type, one job, one path, built properly. This is the MVP approach, and it is the single biggest lever you have.

Test the design before building it. A clickable prototype puts real screens in front of real users without any of it being built; in our projects the full prototype process completes in approximately 3 to 4 weeks. Changing a screen at that stage costs a fraction of changing built software.

Drop native apps if a web app will do. Ask what genuinely requires an app store presence. Push notifications and camera access often do not any more.

Automate later. Manual onboarding or a human reviewing submissions is fine early on. Faking the back office is cheap; faking the user's experience is not.

Do not buy a cheaper supplier to reduce the number. The consistent pattern in the rescue projects we take on is that the saving was recovered, with interest, in the rebuild.

Choosing what goes in the first release

Narrowing scope is easy to agree to and hard to do, because every feature has somebody attached to it. Scoring helps: rate each item on impact — how much it moves the goal you wrote down — and on effort, where effort includes cost, build time and the risk of having to redo it later.

Set the two against each other and most decisions make themselves. High impact and low effort goes first; low impact and high effort waits, however well argued. Questions that help you place an item honestly:

• Will people use it every time they open the app, or once in a while?
• Is it likely to be replaced once you have seen how the app is really used?
• Does it move one of your stated goals, or is it just a good idea?
• Could a person do it by hand for the first few months?
• Does anything else have to have it on day one?

Do this before asking for a final quote and the conversation changes: rather than negotiating a price down, you are deciding what you are buying.

A brief you can copy into your quote request

You do not need all the answers before speaking to us. Mark unknowns clearly so that the initial conversation can focus on them.

• Business outcome: what needs to improve, and how you will judge success.
• People: who will use the app and who will administer it.
• First release: the essential journeys, with later features listed separately.
• Platforms and access: web, iOS or Android; any offline or accessibility needs.
• Existing systems and data: products to integrate, records to import and what access is available.
• Constraints: an indicative budget, a target date and the business reason behind it.
• Existing work: designs, research or software already available, including who owns it.
• Operating plan: likely user numbers, support needs and who will own the product after launch.

For a project-specific estimate, request a free app development quote. For help deciding what belongs in the first release, explore Quickstart App Planning.

Questions to ask before you sign

Five questions separate a firm quote from an optimistic one:

1. What is explicitly not included? The answer should be specific.
2. What happens when we change our minds? Every project changes; you want to know the mechanism and the price of it now.
3. Who owns the code and the data? Get it in writing before work starts.
4. What does it cost to run for a year after launch? Hosting, support and third-party services.
5. What is the plan if it takes longer than expected? Who carries that cost, and how would you find out early?

If a supplier cannot answer the first one precisely, the estimate is not an estimate yet — it is a starting position.

The second question is the one that separates the models in practice. Under a fixed price, changing your mind is a commercial event with a price attached, so the honest suppliers price that mechanism openly rather than pretending change will not happen. Under sprints, changing your mind between sprints is free and expected, but you carry the planning effort each time. Ask which of those you are buying, because a supplier who describes a fixed price and then works in sprints has given you the downsides of both.

How we estimate, and what we do about the uncertainty

Our sequence is deliberately the opposite of one confident number up front.

1. A ballpark early, with its assumptions stated. On a first call we will usually give a rough figure, because you need one to know whether the project is worth pursuing. It rests on early assumptions that may prove wrong, and we say which ones.
2. Planning as separate, paid work. A plan given away free is either not thorough or is being recovered somewhere else in the price. Treat a full proposal arriving after a single thirty-minute call as a warning rather than a service: nobody can responsibly specify several hundred hours of work from that.
3. An itemised estimate you can edit. Once the scope exists the cost breaks down by item, and you choose what stays in the first release and what waits.
4. Delivery in fixed-price sprints or to a fixed scope, with payment staged across delivery — a deposit, then monthly — rather than one invoice up front. We do not offer finance-style payment plans.

Our team is in-house and UK-based, in Birmingham. That is worth knowing when you set our figure against an offshore one, because you are comparing two different things rather than two prices for the same thing. Who owns the code and the data is agreed in writing before work starts.

For the process of getting a project-specific estimate, visit our app development cost page.

Getting a number for your own project

The fastest route to a real figure is to send us the one-page brief above. We will come back with our thoughts, a realistic plan and a rough cost estimate — and if the honest answer is that an off-the-shelf product would serve you better than anything we would build, we will say so.

Two things worth knowing before you send it. You do not need the brief to be complete; the gaps are often the most useful part of the conversation, because they are where the cost is genuinely undecided. And if you already have a part-built app from another supplier, the right first step is not a quote at all but a fixed-fee App Rescue Assessment — a Standard assessment is £3,000 + VAT and most complete within a few working days, which is far cheaper than quoting blind against code nobody has read.

Ask for a free quote with whatever detail you have, or if the scope is still genuinely open, book a free consultation and we will work through it with you first.