How Long Does It Take to Build an App? An Honest Timeline
Search this question and you will get a dozen agency pages quoting the same bands: simple app, eight to twelve weeks; mid-complexity, four to six months; enterprise, a year or more. Those bands are roughly right. They are also close to useless on their own, because they describe the size of the work without telling you where the calendar actually goes.
Here is the part those pages leave out: on most projects that run late, the build was not the bottleneck. Decisions were. This guide walks through a real timeline week by week, names the four things that reliably cause slippage, and is specific about the one delay everybody over-estimates — app store review.
The short answer
For a straightforward business app on both iOS and Android — accounts, a few core screens, push notifications, a payment or booking flow — plan on 10 to 16 weeks from kickoff to live in both stores.
That assumes a defined scope, one decision-maker, and content that exists. Change any of those and the number moves, usually in one direction.
If you want a cost figure alongside the timeline, the app development cost breakdown covers what drives the price, and the free app cost calculator gives you a range in about two minutes.
Where the weeks actually go
Weeks 1–2: Scope and specification
Turning "I want an app that does X" into a screen-by-screen definition of what gets built. Every ambiguity resolved here costs an hour. The same ambiguity resolved in week 9 costs a week, because by then it is entangled with code that already exists.
This is the highest-leverage fortnight in the entire project and the one clients most often want to compress. Resist that.
Weeks 2–5: Design
Wireframes, then visual design, then a clickable prototype you can actually tap through. The prototype matters more than it sounds — it is far cheaper to discover that a flow feels wrong in a prototype than after it is built.
Expect two rounds of revisions. Budget for three.
Weeks 4–12: Build
Overlaps design deliberately: development starts on approved screens while later ones are still being drawn. Front end, back end, integrations, and the unglamorous work — error states, offline behaviour, what happens when a payment fails at exactly the wrong moment.
This is the longest stretch and, counter-intuitively, the most predictable. Well-specified building is estimable work.
Weeks 11–14: Testing and fixes
Real devices, not just simulators. Old Android phones, small screens, bad networks, permissions denied. Then fixing what that turns up.
Teams that treat testing as a phase to compress when the schedule tightens ship the bugs to users instead, and fixing it after launch costs a store review cycle on top.
Weeks 14–16: Store submission and launch
Store listings, screenshots, privacy declarations, review, release. More on this below, because it is smaller than people fear.
App store review is not the delay you think it is
This is where expectations are most wrong. People plan for weeks of review limbo. The real numbers are much better.
Apple states that 50% of submissions are reviewed within 24 hours and 90% within 48 hours (Apple, App Review, as of August 2026). Google Play review typically runs a few days for a new app, longer for the first submission on a brand-new developer account than for subsequent updates.
So budget roughly a week for the submission phase and you will usually have room to spare. What genuinely does cost time is rejection, and rejections are mostly avoidable and mostly boring: a privacy policy that does not match what the app collects, a demo account that does not work for the reviewer, permissions requested without an explanation string, or an app that reviewers cannot fully use because a feature needs data you did not provide.
Every one of those is preventable in the week before you submit. If you need a compliant policy, the privacy policy generator produces one that reflects what your app actually does.
There is one caveat worth naming: a first-time Google Play developer account can face additional identity and testing requirements before a production release, which is a one-time cost on your first app, not a recurring one. Check the current requirements on your developer console rather than assuming, since Google has changed these rules more than once.
The four things that actually make projects slip
Scope added mid-build. Not the request itself — a two-day feature is two days. It is what the request touches. A new field in onboarding can mean changing the database, the API, three screens, and the tests. This is the single most common cause of a project running long.
Slow decisions. A build waits on answers. If a question takes six days to get answered because it needs consensus from four people, that is six days of calendar spent on one email. One empowered decision-maker is worth more to a timeline than an extra developer.
Content that does not exist. Copy, logo, photography, legal text, the terms of service. Design stalls without them, and "we'll write that later" reliably becomes the thing holding up submission in week 15.
Third-party dependencies. A payment processor's underwriting, an insurer's API access, a franchise's brand approval. These run on someone else's clock, and they are the delays you can do least about — which is exactly why they should be started in week 1, not week 12.
Notice that three of the four sit on the client's side of the line. That is not a way of shifting blame; it is the useful part. Those are the delays you can actually prevent.
What a faster timeline really costs
You can compress a build. Adding developers to a well-defined project helps up to a point, and cutting launch scope helps more. But some of it is real time that cannot be bought back — you cannot compress a two-week underwriting review or a three-day store review by paying more.
The version of "faster" that actually works is almost always smaller. Ship the core flow that delivers the value, launch, and add the rest against real usage. An app in the store earning feedback in week 10 beats a more complete app still in testing in week 22, and you will build the second version better for having watched people use the first.
That is also the honest argument against us, or anyone, on some projects: if what you need is a booking form and a payment link, you may not need an app at all. A good agency will tell you that before you spend the money.
How we schedule it
We quote a fixed price and a fixed timeline, and we tell you at the start which milestones depend on you rather than on us — content deadlines, decision points, anything third-party. Those dates get put in the schedule as real dependencies, because a timeline that pretends they do not exist is a timeline that slips in week 12 and surprises everybody.
If you want a specific timeline for a specific idea, the app brief takes about ten minutes and comes back with a scoped plan and dates. If you would rather talk it through first, book a free intro call and we will give you an honest read — including whether an app is the right build at all.
Sources: Apple App Review.
Your app. In the stores. Done for you. US APP Team designs, builds, and launches your iOS and Android app for a fixed price. Start your app brief or book a free intro call — both are free.
Want to poke around first? Every tool in our free tool library runs in your browser with no signup: an app cost calculator, an app name generator, and a privacy policy generator.
