How Long Does It Take to Build an App? A Realistic Timeline From Idea to App Store
How long does it take to build an app? A realistic stage by stage timeline from discovery to App Store review, and what makes projects run late.
A simple app with a handful of screens and no complex back end typically takes around two to three months from agreed scope to the app stores. A typical business app with user accounts, an admin area and integrations is more often four to six months. Anything with payments, real-time features, offline sync or heavy compliance can run well beyond that.
Those ranges are only useful if you know what sits inside them. Below we break a project into its real stages, explain what each one involves, and cover the things that make apps late, which are rarely the coding itself.
Key takeaways
- Simple apps take a couple of months; typical business apps take several months.
- Discovery and design often take as long as people expect the whole build to take.
- The back end and admin panel are usually bigger than the app screens.
- App Store and Google Play review add time you cannot fully control.
- Slow decisions and late changes cause more delay than technical problems.
- Launching a smaller first version is the most reliable way to go live sooner.
Rough timelines by type of app
These are working ranges from our own projects, not promises. They assume a small, focused team and a client who can make decisions quickly.
| Type of app | Example | Typical range |
|---|---|---|
| Simple | Information app, event app, basic catalogue, no logins | 6 to 12 weeks |
| Standard business app | Accounts, bookings, notifications, admin panel, one or two integrations | 4 to 6 months |
| Complex | Marketplace, payments between users, live tracking, offline sync, multiple user roles | 6 to 12 months or more |
The jump between rows is mostly about what happens behind the screens: data, permissions, integrations and edge cases. Two apps that look similar in a mock-up can differ by months.
Stage 1: discovery and scope (2 to 4 weeks)
Discovery is where we agree what the first version does and, just as importantly, what it does not. It covers user types, the main tasks each one needs to complete, the data the app stores, the systems it talks to (a CRM, a booking system, Stripe, an existing website) and any rules around personal data.
The output should be a written scope with user stories and a list of screens. If someone offers to start coding in week one without this, the time saved will come back later as rework. Our guide to a software statement of work shows what a usable scope document contains.
This is also the point to decide platform. Native iOS and Android, or a cross-platform framework such as Flutter or React Native, changes both cost and timeline. We cover the trade-offs in native vs cross-platform apps.
Stage 2: UX and visual design (3 to 6 weeks)
Design starts with wireframes: plain grey boxes that show the flow from screen to screen. It is far quicker to move a button in a wireframe than in a built app, so we push clients to test flows at this stage, ideally with a clickable prototype in Figma on a real phone.
Visual design follows once the flow is agreed. Brand colours, type, icons, empty states, error messages and loading states all need designing. Teams often forget the last three, and they show up later as gaps that slow development.
The length here depends heavily on feedback rounds. Three people giving separate, conflicting comments by email can easily double it. One named decision maker keeps it short.
Stage 3: back end, admin and integrations
Most people picture an app as the screens on the phone. In practice, a large share of the work sits on the server: the database, the API the app calls, user authentication, push notifications, file storage and an admin panel so your staff can manage content, users and orders.
Integrations are where estimates most often slip. Connecting to a well documented API such as Stripe is predictable. Connecting to an older internal system, a supplier's undocumented feed or a CRM with strict rate limits can take weeks of discovery on its own. If your app depends on a third party, ask for sandbox access early.
Back end work usually runs in parallel with the app screens, which is why a team of two or three developers can deliver faster than one person working through everything in order.
Stage 4: building the app (6 to 16 weeks)
We build in short sprints, typically two weeks each, with a test build sent to the client at the end of every sprint through TestFlight for iOS and an internal testing track on Google Play. That way you see real progress on your own phone rather than waiting for a big reveal.
A sensible order is to build the core path first (sign up, the main task, the confirmation) and leave settings, edge cases and nice-to-have features until later. If time runs short, the app still works.
Features that add noticeable time:
- Offline mode with sync when the signal returns.
- Real-time features such as chat or live location.
- In-app purchases and subscriptions, which have their own store rules.
- Multiple user roles with different permissions.
- Accessibility work beyond the basics, which should be planned in rather than bolted on.
Stage 5: testing and fixes (2 to 4 weeks)
Testing happens throughout, but there is always a final round before release. That means testing on a spread of real devices, older iPhones and mid-range Android phones included, on poor connections and with real data rather than three neat test accounts.
User acceptance testing is your team using the app as they would in real life and reporting problems. Allow time for it in your own calendar. A common delay is the client side simply being too busy to test for a fortnight.
Stage 6: app store submission and launch (1 to 2 weeks)
Both stores review apps before they go live. Google Play is usually quicker, and Apple's review is usually a matter of days, but a rejection means fixing the issue and resubmitting. Common reasons for rejection include missing privacy details, login-only apps without a demo account for the reviewer, and apps that are little more than a wrapped website.
You also need store listings ready: screenshots at the right sizes, descriptions, a privacy policy URL and the data safety or privacy label answers. Set up your Apple Developer and Google Play developer accounts early, as organisation accounts need a D-U-N-S number and verification, which can take a while for a new company.
What makes app projects run late
Looking back across projects, the delays we see most often are not technical:
- Scope creep. New ideas added mid-build. Each one is small; together they add months.
- Slow feedback. A sprint review that takes two weeks to come back halves the pace.
- Content not ready. Copy, images, product data and legal text arrive late.
- Third-party access. Waiting on API keys or a supplier's developer.
- Store accounts. Developer account verification not started until launch week.
The fix for most of these is a smaller first release. Our article on which features belong in an MVP helps you decide what can wait for version two.
How to get to launch sooner
If the deadline matters, these are the levers that actually work: cut the first version down to one core task done well, launch on one platform first if your users lean heavily one way (see iOS or Android first), use a cross-platform framework, and appoint one decision maker with time in their diary.
What does not work is adding more developers late in a project. They need time to get up to speed, and coordination costs rise. Budget also tracks time closely, so our guide to app development costs in the UK is worth reading alongside this one, and you can see how we run builds on our process page.
Frequently asked questions
How long does it take to build a simple app?
A simple app with a few screens, no user accounts and little back end work usually takes six to twelve weeks from agreed scope to release. Design feedback and app store review are often the parts that stretch it.
Can an app be built in a month?
A very small prototype or proof of concept can be, but a polished app ready for the public is rarely realistic in four weeks once design, testing and store review are included. A month is better used to build and test a clickable prototype.
How long does Apple take to approve an app?
Apple review is usually a matter of days. If the app is rejected you need to fix the issue and resubmit, so allow a week or two in your plan for the first release rather than assuming approval on the first attempt.
Is it faster to build for iOS and Android at the same time?
With a cross-platform framework such as Flutter or React Native, building both together adds relatively little time. With separate native apps you are effectively running two builds, so launching one platform first is often quicker.
Why do app projects take longer than quoted?
Usually because the scope grows during the build, feedback is slow, or third-party systems are harder to integrate than expected. A written scope, one decision maker and a smaller first version keep timelines much closer to the plan.
Plan your app with a realistic timeline
If you have an app idea and want an honest view of how long it would take, have a look at our mobile app development service, then get in touch or request a quote. We will help you decide what goes into version one.
