How Long App Builds Actually Take in the UK
Most UK app projects take between 8 weeks and 9 months. A simple MVP runs 8 to 14 weeks. A standard app with logins, payments and a backend takes 4 to 6 months. A complex app with custom integrations, real-time features or strict compliance can take 7 to 9 months or more. Our UK mobile app development service sizes the work before any code starts.
These are calendar weeks, not just coding days. They assume one small, focused team and a client who replies to questions within a day or two. The single biggest variable is not the technology. It is how quickly decisions get made on your side, and how clearly the app is defined before work begins.
Why does the timeline range so widely?
Two apps can both be "a booking app" and take wildly different amounts of time. One uses a card payment provider out of the box. The other needs to talk to an old NHS-adjacent system, support offline use on a building site, and pass a security review. The feature list looks similar on a sales call. The build is not.
Timeline depends on three things. The number of distinct screens and user journeys. The number of third-party systems the app must connect to. And the level of compliance, security or accessibility the sector demands. A consumer loyalty app sits at one end. A fintech or healthcare app sits firmly at the other, where the UK regulatory bar is high.
What counts as "built" in the first place?
Be careful what you measure. "Built" should mean live in the App Store and Google Play, tested, with analytics running and a support plan in place. Some quotes quietly stop at "code complete", which skips testing, store submission and the fixes that always follow a real launch. That gap is often two to four weeks of work on its own.
Throughout this guide, our timelines mean from kick-off to a published, working app that real users can download. That is the number that matters to your business, and the one we hold ourselves to.
The Five Phases of an App Build
Every app, from the simplest MVP to a regulated platform, moves through the same five phases. The phases do not change. Only their length does. Understanding them helps you read a quote honestly and spot where a supplier has left something out.
Phase 1: Discovery and planning
Discovery turns a rough idea into a buildable plan. It covers user research, defining the core journeys, choosing the platform approach, and writing the specification the build runs against. For an MVP this might be one to two weeks. For a complex app it can run three to four weeks, because the integrations and compliance need mapping before anyone commits to an estimate.
Skipping discovery feels efficient. It is the most expensive shortcut in app development. A vague spec leads to rework, and rework is where timelines quietly double.
Phase 2: Design (UX and UI)
Design splits into two parts. UX maps how the app flows, screen by screen, usually as wireframes. UI adds the visual layer, the brand, the colour and the polished prototype you can click through. A small app needs two to three weeks. A feature-rich one needs four to six. Good design here saves development time later, because developers build from clear screens rather than guessing.
The UK accessibility standard matters at this stage too. Designing to WCAG 2.2 AA from the start is far cheaper than retrofitting it after launch.
Phase 3: Development
Development is the longest phase, normally 40 to 50 percent of the total timeline. It covers the front end (what users tap), the back end (the server, database and logic) and the integrations (payments, maps, push notifications, login). For an MVP this is roughly four to six weeks. For a standard app, eight to fourteen. For a complex build, three to five months and sometimes longer.
Choosing cross-platform tools such as Flutter or React Native can compress this phase, because one codebase serves both iOS and Android. Native builds take longer but suit performance-heavy apps. We cover that trade-off in detail separately.
Phase 4: Testing and QA
Quality assurance is where corner-cutting shows up later as one-star reviews. QA covers functional testing, device testing across real iPhones and Android handsets, security checks and accessibility checks. Budget two to four weeks for most apps, run in parallel with the last stretch of development. Regulated apps need longer, sometimes with an external penetration test.
UK device fragmentation is real. According to StatCounter, iOS and Android both hold large shares of the UK market, so you cannot test on one and assume the other works.
Phase 5: Store submission and launch
The final phase is preparing store listings, submitting to Apple and Google, passing review and going live. Allow one to two weeks. Apple's review is the unpredictable part, which deserves its own section below. This phase also includes the first round of post-launch fixes, because real users always find what test users miss.
Timelines by Complexity Tier
Here is how those five phases add up across the three tiers UK businesses commonly commission. The ranges assume a focused team and prompt decisions on your side. Pricing follows the same pattern, which we break down in our dedicated cost guide.
How long does an MVP take?
An MVP, or minimum viable product, proves one idea with the fewest features that make it useful. Think a single core journey, basic accounts and one payment flow. Expect 8 to 14 weeks. This is the right starting point for most startups and any business testing demand before committing a large budget. It gets you real users and real feedback fast, which is worth more than a long wish list of features nobody has validated.
The trap is letting the MVP grow. Every "while we're at it" feature pushes the launch back. Discipline at this stage is what keeps an 8-week build from becoming a 6-month one.
How long does a standard app take?
A standard app is what most established UK SMBs need. It has multiple user roles, secure logins, payments, push notifications, an admin dashboard and a proper backend. Expect 4 to 6 months. A loyalty app for a retail chain, a booking app for a clinic, or an internal tool for field staff usually sits here. The integrations and the admin side are what stretch the timeline beyond MVP territory.
This tier benefits most from cross-platform development, because the savings compound across more screens and two app stores at once.
How long does a complex app take?
Complex apps carry real-time features, heavy data, multiple integrations, or sit in a regulated sector such as finance, health or insurance. Expect 7 to 9 months, sometimes longer. Compliance with rules from bodies like the FCA for financial products, or strict UK GDPR handling for sensitive data, adds weeks of design, build and review. The extra time is not waste. It is the difference between launching and getting pulled from the store.
What App-Store Review Adds
Once your app is built and tested, you still need Apple and Google to approve it. This is a real chunk of the timeline that cheap quotes love to ignore. Plan for it, and a rejection costs you days. Ignore it, and it costs you weeks.
How long does Apple App Store review take?
Apple reviews most apps within 24 to 48 hours, and according to Apple's own guidance a large majority are reviewed inside two days. The catch is rejection. Apple is strict about its guidelines, and first submissions get bounced for small reasons: a missing privacy label, an unclear sign-in flow, or a feature that looks like it belongs in a web view. Each rejection means a fix and a fresh review cycle. We budget one to two weeks for the whole submission window precisely because the first try rarely sails straight through.
How long does Google Play review take?
Google Play is usually faster for established developer accounts, often a few hours to a couple of days. Brand-new developer accounts now face extra verification and sometimes a longer first review, so a first-ever launch on Google can take longer than you expect. Google is stricter than it used to be on permissions and data-safety declarations. Get the data-safety form wrong and the app stalls. We prepare both store listings during the QA phase so submission is not a last-minute scramble.
A Cardiff clinic asked us for a booking app and wanted it live in six weeks for a marketing push. We were honest: the booking journey alone was fine, but they also wanted online payments and clinician logins, which pulled it into standard-app territory. We agreed a phased plan. We shipped a 9-week MVP with booking and reminders for the campaign, then added payments and the staff dashboard over the following two months. The campaign hit its date, and the clinic launched on a working app instead of a broken rush job. Splitting the build saved the deadline and the reputation.
What Slows a Project Down
Most delays are not technical. They are human and organisational. Knowing the usual culprits lets you plan around them before they cost you weeks.
Decisions, content and access
The fastest projects have one decision-maker who replies quickly. The slow ones route every choice through a committee. A developer waiting three days for an answer on a button label is a developer not building. The same applies to content: app copy, images, terms and legal text are your responsibility, and missing content stalls real screens. Third-party access matters too. If the app connects to your payment provider or booking system, late credentials block the integration phase entirely.
Scope creep and unclear requirements
Scope creep is the timeline killer. Every new feature added mid-build does not just take its own time; it ripples into design, testing and sometimes the backend. A vague spec causes the same problem more slowly, through endless clarification rounds. The fix is a tight, written specification agreed before development starts, with a clear change process for anything new. New ideas are welcome. They just go in the next phase, not this one.
Pro tip: Lock your specification before development begins and keep a written "phase two" list for every new idea. It is not a no, it is a not yet. This single habit is the most reliable way to protect both your launch date and your budget.
How to Build Faster Without Cutting Corners
You cannot rush testing or store review without paying for it later. You can, however, remove the avoidable delays. These levers genuinely compress a timeline without harming quality.
Start with an MVP, then iterate
The single biggest speed-up is building less, sooner. Ship the core journey, learn from real users, then add features in planned waves. This gets you to market in weeks rather than months and means your later development is informed by data, not guesswork. It also spreads cost over time, which suits cash-flow for most UK SMBs far better than one large upfront build.
Choose cross-platform where it fits
For most business apps, a single cross-platform codebase serves both iOS and Android. This roughly halves the development phase compared with building two native apps separately. Native still wins for graphics-heavy or hardware-intensive apps, but for the typical booking, loyalty or internal tool, cross-platform is the faster, sensible default. The right choice depends on your app, and it is worth a proper conversation early.
Run design, build and QA in parallel
A good team does not work in a rigid straight line. Designers polish later screens while developers build earlier ones. QA tests finished features while the rest are still in progress. This overlap, run by an experienced project lead, shaves real weeks off a sequential plan without anyone working faster or longer.
| Tier | Discovery | Design | Development | QA + Launch | Total |
|---|---|---|---|---|---|
| MVP | 1–2 wks | 2–3 wks | 4–6 wks | 1–3 wks | 8–14 weeks |
| Standard | 2–3 wks | 3–4 wks | 8–14 wks | 3–4 wks | 4–6 months |
| Complex | 3–4 wks | 4–6 wks | 12–20 wks | 4–6 wks | 7–9 months |
Common Timeline Mistakes to Avoid
- Skipping discovery — starting development on a vague brief guarantees rework, which is where timelines quietly double.
- Ignoring store review — assuming the app goes live the moment code is finished. Apple and Google add one to two weeks.
- Counting coding days, not calendar weeks — feedback rounds, holidays and approvals all consume real time.
- Mid-build scope creep — every "small" feature added during development ripples into design, testing and the backend.
- Slow client responses — a developer waiting days for a decision or for content is a developer not building.
- One person testing one phone — the UK splits between iOS and Android, so single-device testing hides launch-day bugs.
- No buffer for the unknown — sensible plans hold back 10 to 15 percent of the timeline for the issues every project finds.
6 Frequently Asked Questions
Rarely, and only for a very narrow MVP with one screen, no payments and no backend. Most useful apps need 8 weeks minimum once you include discovery, design, proper testing and store submission. Anyone promising a full-featured app in four weeks is either skipping QA or quietly using a template that you will outgrow fast. A month is realistic for a clickable prototype or a no-code experiment to test demand, but not for a polished, published app that handles real user data and survives contact with the App Store review team.
Not if you build cross-platform. With Flutter or React Native, one codebase serves both stores, so development is far closer to a single-platform timeline than double it. You still test on both, and each store has its own submission and review, which adds a little time. Building two separate native apps does roughly double the development phase, which is why most UK business apps go cross-platform unless they need heavy graphics or deep hardware access. We talk through the choice early because it shapes both the timeline and the budget.
Plan for one to two weeks across both stores. Apple usually reviews within 24 to 48 hours, but first submissions often get rejected for small guideline issues, and each fix triggers a fresh review. Google Play is often faster for established accounts but slower for brand-new developer accounts that need extra verification. The actual review time is short. The buffer exists because rejection-and-resubmit cycles are common on a first launch. Preparing both store listings during the QA phase, rather than after it, keeps this window as short as possible.
Slow decisions and scope creep on the client side, not the code. The fastest projects have one empowered decision-maker who replies within a day, supplies content on time, and resists adding features mid-build. The slowest ones route everything through a committee and keep changing the brief. A clear written specification agreed before development, plus a defined process for new ideas, removes most avoidable delay. Technology rarely sets the limit on a well-run project; the speed of approvals and the discipline around scope almost always do.
Phase it whenever you can. Shipping a focused MVP first gets you to market in weeks, puts the app in front of real users, and lets later features follow real feedback instead of guesswork. It also spreads cost over time, which suits cash-flow for most UK SMBs. A big-bang launch with every feature on day one carries more risk, takes far longer, and often ships things users never wanted. Phasing is how we hit tight marketing deadlines without rushing the parts that genuinely need care, such as payments and security.
Yes. Apps in finance, health or insurance carry extra compliance work at every phase. Sensitive data must be handled to UK GDPR standards, financial products may fall under FCA rules, and security often needs an external penetration test before launch. That adds weeks of design, build and review, pushing a build firmly into the complex tier of 7 to 9 months or more. The time is not optional padding. Cutting it risks a store rejection, a data breach, or regulatory action that costs far more than the weeks saved.
Working out how long your app will take starts with a clear picture of what it needs to do. At Cambria Digital we have delivered 100+ UK projects, and we size every build before a line of code is written, so the timeline you see is one we can hold ourselves to. Book a free discovery call and we will map your app's phases in 30 minutes, or read more about our UK mobile app development service to see how we work. No obligation, reply within 1 business day.