What an App Quote Actually Pays For
An app development quote pays for nine things, not just coding: discovery, UX/UI design, the frontend, the backend and API, third-party integrations, testing, app store submission, post-launch support, and a contingency buffer. Coding the screens you can see is often less than half the bill. The rest is the work that makes the app reliable.
If you have a number in front of you and you are not sure where it came from, this guide breaks it apart phase by phase, with a rough share of budget for each. We are not repeating the headline figure here — for total ranges, read our full guide on how much mobile app development costs in the UK. This piece is about reading the invoice, line by line. If you want a quote you can actually understand, our UK mobile app development team itemises every phase before you commit.
Why does the same app get quoted at wildly different prices?
Two agencies can quote the same idea at £18,000 and £55,000 and both be honest. The gap is rarely the screens. It is the assumptions underneath them. One quote assumes a simple login and a public API; the other assumes secure user accounts, offline support, payment compliance, and a year of bug fixes. One bills for QA as a real phase; the other hopes nothing breaks. When you cannot see the line items, you are not comparing prices — you are comparing guesses. The breakdown below shows you exactly where that money hides, so you can ask the right questions instead of just picking the lowest figure on the page.
The Line-by-Line Breakdown
Here is every phase a complete quote should name, with a rough percentage of a typical UK project budget. Percentages shift by project, but if a phase is missing entirely, that is a flag to ask about.
Discovery and scoping — roughly 5–10%
Discovery is where the team works out what you are actually building. It covers requirement workshops, user stories, a feature list, a technical approach, and sometimes wireframe sketches. Skipping it feels like saving money. It is the opposite. Most overruns we see trace back to a vague brief that nobody pinned down before coding started. A few thousand pounds of discovery on a £30,000 build routinely saves five figures in rework. Expect a written scope document at the end — a one-line email is not discovery. If a quote shows £0 for this phase, the cost has not vanished. It has been pushed into change requests you will pay for later, usually at a worse rate.
UX and UI design — roughly 10–20%
UX is how the app flows; UI is how it looks. This phase produces user journeys, wireframes, then polished screens, usually in Figma. Good design is not decoration — it is the difference between an app people keep and one they delete after a week. On a consumer app this share runs higher; on an internal tool it runs lower. The deliverable should be a clickable prototype you can tap through before a single line of code exists. That prototype is your cheapest chance to change your mind. Moving a button in Figma costs minutes; moving it after the backend ships costs days. If design and build are quoted as one undivided lump, ask to see the design milestones separately.
Frontend development — roughly 25–35%
This is the part you see and touch: the screens, navigation, animations, and forms. It is usually the single biggest line. The cost swings on platform choice. A cross-platform build with Flutter or React Native produces one codebase for iOS and Android, which is cheaper than two native apps but carries trade-offs on deep device features. Native Swift and Kotlin cost more because you build twice. Neither is wrong — it depends on your app. What matters in the quote is that the platform decision is stated and priced, not assumed. If the quote says "mobile app" with no mention of approach, you do not yet know what you are buying.
Backend, API and database — roughly 20–30%
The backend is the engine you cannot see: the server, the database, the API that feeds the app, user accounts, and security. Any app that stores data, logs people in, or talks to another system needs one. This is the phase clients underestimate most, because nothing on screen represents it. Yet a weak backend is how apps leak data and crash under load. It also carries legal weight — if you store UK customer data you sit under UK GDPR and the ICO, and the build has to reflect that. A purely offline tool may skip most of this line. An app with logins, payments, or live data cannot. If the backend share looks tiny, check whether the quote quietly assumes you already have one.
Third-party integrations — roughly 5–15%
Integrations are the external services your app plugs into: Stripe for payments, mapping, push notifications, analytics, a CRM, or a booking system. Each one is its own small project. The service might be free or cheap, but wiring it in, handling errors, and testing edge cases takes real hours. Payments are the classic underestimate — handling a successful charge is easy; handling refunds, failed cards, and disputes safely is not. A good quote lists every integration by name with a line each. A vague "third-party APIs as required" is a blank cheque. List yours up front, because each one you add after the quote is a change request, and change requests are where budgets slip.
QA, testing and bug fixing — roughly 10–15%
QA is structured testing across devices, screen sizes, and operating system versions, plus fixing what it finds. An iPhone 15, a five-year-old Android, and an iPad do not behave the same, and your users own all three. Skipping this phase does not remove the bugs — it just moves their discovery to your customers and their one-star reviews. On a serious build, expect dedicated test cycles, not a quick look on the developer's own phone the day before launch. If a quote shows no QA line, the testing is either missing or buried inside development hours where you cannot see it. Either way, ask. This is one of the first phases a cheap quote quietly drops to win on price.
App store submission and launch — roughly 1–3%
Getting onto the stores is its own small job. It covers store listings, screenshots, the privacy nutrition labels Apple requires, app icons, and managing the review process. Apple's App Store review rejects apps for reasons that surprise first-timers — missing privacy detail, thin content, or broken links. Budget the agency time to handle rejections, because a first submission rarely sails through. Note the separate, ongoing developer account fees too: Apple charges an annual fee and Google charges a one-off registration. Those are yours to pay, not the agency's, and a tidy quote names them so there is no surprise on launch week.
Post-launch support and contingency — roughly 10–15%
The day you launch is the start, not the end. Operating systems update, devices change, and real users do things you never predicted. Post-launch support covers monitoring, bug fixes, and small tweaks in the first weeks. Contingency is a deliberate buffer for the unknowns every project has. A quote with zero contingency is not cheaper — it is just hiding the risk, and you will meet it as an overrun. Decide up front whether support is a fixed period, a monthly retainer, or pay-as-you-go, and get it in writing. The cheapest moment to agree how bugs get fixed is before launch, not at 9pm when the app is down and nobody is sure who is on the hook.
A Cardiff service business came to us with two app quotes that looked miles apart — one around £20,000, one near £45,000. We sat down and mapped each against the nine phases here. The cheaper quote had no discovery, no separate QA line, and a single line that read "backend setup". It assumed a basic build with manual testing. The dearer one priced secure logins, Stripe with refund handling, real test cycles, and three months of support. They were not the same app at all. Once both were laid out phase by phase, the client could finally compare like for like — and chose based on what they actually needed, not the headline number.
Quick test for any quote: ask the agency to send the same number broken into the nine phases above. A team that knows its work can do this in a day. A team that cannot, or will not, is a team that has not thought the project through — and that is the real risk to your budget.
The Lines Cheap Quotes Leave Out
The phases above are the visible work. The trouble starts with the lines a low quote quietly omits, then bills for later. Knowing them in advance is how you avoid the surprise.
What ongoing costs does the quote not include?
A build price is a one-off. Running an app is not. After launch you keep paying for hosting and servers, the Apple and Google developer accounts, third-party service fees as you scale, and ongoing maintenance for OS updates. None of that belongs in the build quote, but a good agency tells you about it anyway, because it shapes your real budget. We have seen owners celebrate a fixed build price, then get blindsided by £2,000–£6,000 a year of running costs nobody flagged. Ask for a separate "cost to run, per year" estimate alongside the build quote. If the agency cannot give you one, they have not thought past launch day — and neither, yet, have you.
| Phase | Typical % of build | What you get | Cut-corner risk |
|---|---|---|---|
| Discovery and scoping | 5–10% | Written scope, feature list | Scope creep, rework |
| UX / UI design | 10–20% | Clickable prototype | App people delete |
| Frontend | 25–35% | The screens you use | Wrong platform choice |
| Backend / API | 20–30% | Server, data, security | Data leaks, crashes |
| Integrations | 5–15% | Payments, maps, CRM | Blank-cheque add-ons |
| QA / testing | 10–15% | Multi-device testing | Bugs found by users |
| App store submission | 1–3% | Listings, review handling | Rejections, delays |
| Post-launch + contingency | 10–15% | Support, buffer for unknowns | Overruns, no support plan |
How to Read and Compare Two Quotes
When two quotes land in your inbox, the lowest number is the wrong place to start. Read them as a checklist instead.
What questions should I ask before I sign?
Run every quote through the same short list. Is each of the nine phases named, or are some missing? Is the platform stated — cross-platform or native — and is the choice explained? Are integrations listed by name, or hidden behind "as required"? Is QA a real line or absent? What does post-launch support actually include, and for how long? Are ongoing running costs spelled out separately? Is there a contingency, and how big? A quote that answers all of these clearly is usually the safer bet even if it is dearer, because the gaps in the cheaper one are not savings — they are deferred bills. The clearest quote, not the cheapest, is the one that protects your budget. When you compare on phases rather than totals, the right choice gets a lot more obvious.
Common Mistakes to Avoid
- Picking the lowest number — the cheapest quote usually wins on price by dropping discovery, QA, or support you will need later.
- Treating the build price as the total cost — hosting, developer accounts, and maintenance run £2,000–£6,000 a year and rarely sit in the build quote.
- Accepting "third-party APIs as required" — that is a blank cheque. List every integration by name before you sign.
- Skipping discovery to save money — a vague brief is the single biggest cause of overruns we see.
- Assuming one quote means one app — two quotes for "the same idea" are often two very different builds underneath.
- No contingency line — a quote with zero buffer is not cheaper, it has just hidden the risk in your lap.
- Forgetting UK data rules — if the app stores customer data, UK GDPR applies, and that obligation belongs in the backend scope.
6 Frequently Asked Questions
The backend is the engine room. It runs the server, the database, the API the app talks to, user logins, and security. None of it shows on screen, which is exactly why people underestimate it — yet it is where data is stored and protected. A weak backend is how apps leak information, crash under load, or fall foul of UK GDPR. For any app with accounts, payments, or live data, the backend is 20–30% of the build for good reason. If you see a tiny backend line on a quote for a data-heavy app, ask whether the agency assumes you already have one, because that assumption can quietly remove a third of the real work.
Both work, but they suit different projects. Fixed price gives you certainty and suits a well-defined build where discovery is done and the scope is locked. The catch is that anything outside that scope becomes a change request. Time and materials bills for actual hours and suits projects where the path will shift as you learn — common for genuinely new ideas. The honest answer is that a fixed price is only as good as the scope behind it. A fixed number on a vague brief is a trap, because every clarification becomes a paid extra. Whichever model you pick, insist on a clear scope document first. That document, not the pricing model, is what really protects you.
The build price is a one-off; running the app is not. Expect hosting and server costs, an Apple Developer account fee each year and a one-off Google Play registration fee, third-party service charges that grow with usage, and ongoing maintenance to keep the app working as iOS and Android update. For a typical UK small-business app, running costs often land somewhere between £2,000 and £6,000 a year, though a heavily used app with paid integrations runs higher. These rarely belong in the build quote, so ask for a separate "cost to run, per year" figure. An agency that cannot give you one has not planned past launch day, and that is worth knowing before you commit.
Cross-platform frameworks like Flutter or React Native build one codebase that runs on both iOS and Android, which usually costs less than building two native apps. The trade-off comes with deep device features and the most demanding performance, where native Swift and Kotlin still have the edge. For most business apps, cross-platform is the sensible default. For a graphics-heavy game or something leaning hard on niche hardware, native may be worth the extra. What matters in the quote is that the choice is named and priced, not assumed. A quote that just says "mobile app" with no mention of approach leaves you unable to judge whether the number is fair, so always ask which path they have costed and why.
Discovery is usually 5–10% of the build, and skipping it is the most expensive saving you can make. It produces a written scope, a feature list, and a technical approach — the things that stop a project drifting. We see most overruns trace back to a brief nobody pinned down before coding began. A few thousand pounds of discovery on a £30,000 build routinely saves five figures in rework, because changing your mind on paper is cheap and changing it mid-build is not. If a quote shows £0 for discovery, the cost has not disappeared. It has moved into change requests you will pay for later, often at a worse rate than if you had scoped it properly up front.
A good arrangement is written down before launch, not improvised after. It should state what is covered — bug fixes, monitoring, OS-update maintenance — and what is not, such as new features. It should set a structure: a fixed support window, a monthly retainer, or pay-as-you-go, with response times you both accept. The worst position is no agreement at all, where a critical bug appears and nobody is sure who fixes it or who pays. Apps are living products; operating systems and devices change, and something always needs attention in the first weeks. Agree the support model while you still have leverage, during the build, and put it in the contract. The cheapest time to settle this is long before you actually need it.
Got an app quote and still not sure what you are paying for? At Cambria Digital we have delivered 100+ UK projects, and we itemise every quote against the nine phases above so you can see exactly where your budget goes. Book a free discovery call and we will walk through your quote with you in 30 minutes, or read more about our UK mobile app development service to see how we scope a build. No obligation, and we reply within 1 business day.