A useful first version of an app takes three to six months for most businesses. The engineering is rarely what decides where you land in that range. Decisions, content, third-party access and approvals do, and all four sit on the client's side of the table.
This is a planning problem rather than a complaint about clients, and it is fixable once you know which weeks are genuinely at risk. Here is where the calendar goes.
How long does it take to build an app?
Three to six months to a first version that real users can use, on our own delivery experience of business apps and internal platforms. A single-process internal system can ship in six to ten weeks. A consumer product with payments, accounts and two app stores runs longer, and anything carrying regulatory obligations runs longer again.
Those bands are ours rather than an industry standard, and they assume one thing that is often untrue: that someone on your side can make a decision within a few days of being asked.
Why do app projects run late?
Because half of them do, and have for a decade, mostly for reasons that predate the code. A 2025 longitudinal update in PM World Journal (January 2026) tracked Standish Group CHAOS data across the 2020 to 2024 cycle and found 50 per cent of IT projects challenged, meaning late, over budget or delivered short of scope, with 31 per cent succeeding outright. Those numbers have barely moved in ten years of better tooling.
The same paper reports that the primary root cause has shifted since its 2017 analysis, away from poor requirements gathering and towards data maturity and strategic alignment. In delivery terms, the projects that slip are the ones where nobody can say what the software is for, or where the data it depends on turns out not to exist in the shape everyone assumed.
Where do the weeks actually go?
Not where most people expect. On a typical three to four month build, this is roughly how the calendar splits in our experience:
The part everyone worries about, store review, is the smallest slice. Apple states that 90 per cent of submissions are reviewed in under 24 hours. Rejection is what costs time, and Apple says over 40 per cent of unresolved issues relate to guideline 2.1 on app completeness: crashes, placeholder content, missing demo account credentials. Those are avoidable in the week before submission, not in the review queue.
Integrations are the slice that hurts. Connecting to your accounting system, your CRM or a supplier's ordering platform depends on a third party's documentation, sandbox and support desk. We have lost more weeks to waiting for API credentials from someone else's IT department than to any technical problem.
Does AI make app development faster?
It makes writing code faster, and it has not made shipping software faster in any reliable way. Google's 2025 DORA research found 90 per cent of technology professionals now use AI at work and over 80 per cent believe it has raised their productivity, while higher AI adoption correlates with an increase in both delivery throughput and delivery instability. Time saved generating code gets spent verifying it.
For planning purposes, AI has compressed the build phase, which was 30 to 40 per cent of the calendar, and left the decision-making, integration and approval phases exactly where they were. A 20 per cent gain on a third of the timeline is real, and it is not enough to change the date you give the board. We covered what that means for what you pay in our piece on AI and what agencies charge.
How do you make an app project go faster?
Shrink the scope and shorten the decision loop, in that order. The two changes that consistently save the most calendar time cost nothing:
- Name one decision-maker with authority. Not a committee, and not someone who has to take every question upstairs. Most slipped weeks are questions sitting in an inbox.
- Start the third-party access requests in week one. API keys, sandbox accounts, data exports from the incumbent supplier. These have lead times you do not control and they are the commonest cause of a stalled sprint.
- Cut the feature list before you start, not in month three. Every feature carries design, build, test and support time, and most of them are not why anyone will use the product. The argument for cutting hard is in how many features an MVP should have.
- Get the content and data ready in parallel. Copy, images, product data and the migration from the old system are jobs that can run alongside the build and almost never do.
The fastest projects we have delivered were not technically simpler. They had one person who could say yes, and a scope small enough that saying yes was low risk. Working out what belongs in that scope is the entire point of our discovery process.