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.

If you want our detailed breakdown of UK pricing specifically, that lives on our app development cost page. This guide is about something different and more useful before you get quotes: understanding which of your own decisions are moving the number, so you can change them.

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.

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.

Write a brief that gets you an accurate quote

You can dramatically improve the quality of the estimates you receive with one page. Write down:

• Who uses it, as a list of user types, and what each one may see and do.
• The three things it must do on day one, and what you would be willing to drop.
• Which systems it must talk to, naming the products and whether they have an API.
• Which platforms, and whether offline use is genuinely required.
• Roughly how many users in year one and year three.
• What success looks like, as a number — hours saved, enquiries handled, revenue unlocked.

That last point is worth more than it looks. A supplier who knows the app is meant to save twelve hours a week can tell you when a feature is not worth its cost. Without it, every suggestion sounds equally reasonable and the scope only ever grows.

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.

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.