How long does it take to build an app is the question everyone asks second, right after cost, and the answers online are useless because they quote build time and leave out everything around it. A team can be finished in eight weeks and the app can reach customers four months later.
The building is usually the predictable part. The waiting is not, and nobody puts it in the plan. So here is the whole thing, phases and gaps, and the four things that reliably double it.
How long it takes to build an app, phase by phase
| Phase | Simple app | Substantial app | What happens |
|---|---|---|---|
| Working out what to build | 1 to 2 weeks | 3 to 6 weeks | Deciding what the first version does and, more importantly, does not. Skipped often, and it is where the schedule is actually decided. |
| Design | 2 to 3 weeks | 4 to 8 weeks | Screens, flows and a clickable version to react to. Running this ahead of the build rather than alongside it is what keeps the build from stalling. |
| Building | 6 to 10 weeks | 4 to 8 months | The part everyone quotes. Reasonably predictable once the first two are done properly. |
| Testing and fixing | 1 to 2 weeks | 4 to 8 weeks | Real devices, real conditions, real people. Compressed more often than any other phase and it always resurfaces later. |
| Store submission | 1 to 3 weeks | 1 to 3 weeks | Preparing the listing, then review, then usually a rejection round. Not proportional to app size. |
| The fortnight after launch | 2 weeks | 2 to 4 weeks | Something always needs attention. Plan it and it is uneventful. |
Illustrative ranges from the kind of work we quote, not a promise. Roughly three to five months for a genuinely simple first version, and eight to fourteen months for something substantial, assuming nothing on the next list happens.
The waiting nobody budgets for
Four gaps that appear in almost every project and in almost no plan.
- Your own feedback. A build stops while it waits for a decision or a review. Two days of your attention spread over three weeks is three weeks of elapsed time. This is the single largest source of slippage and it is entirely within your control.
- Content and assets. Photographs, descriptions, terms, a privacy policy, the copy for every empty state. Nobody is assigned this and it holds up launch far more often than code does.
- Store review. A first submission takes longer than an update, approval is a reviewer's judgement rather than a checklist, and you should assume at least one rejection round. Nobody can promise a date, and app rejected by Apple covers what to do when it happens.
- Third parties. A payment provider's approval, an integration partner's sandbox, a client's IT department granting access. Each one is somebody else's queue and none of them are on your plan.
Add them up and a fourteen-week build becomes a five-month project without anyone doing anything wrong. Which is why a plan that shows only build time is not a plan, it is an estimate of the fun part.
The four things that double it
- Not deciding what to leave out. A first version that must do everything is the most reliable way to double a timeline, and the decision costs nothing except discomfort. How much does an MVP cost has the leave-out list.
- Changing direction mid-build. Not the same as changing your mind, which is normal and healthy. This is changing what the app is for after the foundation assumes something else.
- Two platforms, built separately. Genuinely close to double for the build and permanently double thereafter. Frequently the honest answer is one platform first, or a shared codebase, or turning your website into an app, which is a much shorter project.
- Integrations discovered late. Every connection to another system carries its own timeline that you do not control. Find them in week one, not week nine.
How to make it genuinely faster
The levers that work, roughly in order of effect.
- Cut scope, not corners. The only lever that reliably shortens a project without a cost elsewhere. Half the app in half the time, then decide what else is needed once real people are using it.
- Name one decision-maker. Not a committee. Distance between a question and an answer is the most expensive thing in a schedule.
- Book your review time in advance. Put the demo dates in a calendar at the start. This alone removes most of the feedback delay.
- Assign the content in week one, to a named person, with dates. It is not a small job and treating it as one is why launches slip.
- Prototype before building. Two to three weeks that removes most of the mid-build direction changes, because you found the problem while it was still rectangles. That is what our prototyping work is for.
- Ship to a small group first. A limited release finds the real problems while the audience is forgiving.
What is happening while nothing seems to happen
A recurring source of friction, worth understanding because it prevents a lot of unnecessary anxiety. There are stretches of an app project where progress is real and invisible, and stretches where visible progress is misleading.
- Weeks one and two look like nothing. Setting up the foundation, the accounts, the build pipeline, the way the app talks to your data. Nothing to show, and skipping it is how a project spends month five fighting its own plumbing.
- Screens appear quickly, then stop. The visible parts come together fast because they are the easy half. The long middle is everything behind them: what happens when the connection drops, when two people edit at once, when the data is missing, when someone taps twice.
- Edge cases take longer than features. A feature is a day. The eleven ways it can fail are a week. Teams that appear slow in month three are frequently the ones whose app works in month nine.
- Testing looks like the end and is not. The build being finished and the app being ready are separated by real devices, real conditions and real people, which is where the last surprises live.
The practical response is to ask for something you can click every two weeks from the start rather than a status report. Working software cannot be optimistic in a way a written update can, and it converts an anxious project into an observable one.
What a supplier cannot promise
Worth saying plainly, because a confident date is often a warning rather than reassurance.
Nobody controls store review, so nobody can promise a launch date that depends on it. Nobody can promise a date that assumes your feedback arrives on time unless you have agreed when it will. And any date given before the first two phases are done is a guess wearing a suit, however precise it sounds.
What can honestly be committed to is the shape: this phase takes this long, here is what we need from you and when, here is where the uncertainty sits. A supplier who tells you what they are unsure about is more reliable than one who is confident about everything, and red flags in a software proposal covers the rest of that judgement.
Two platforms, and whether you need both
The decision with the largest effect on the timeline, usually made by default rather than deliberately.
Building separately for both platforms is close to double the build and permanently double the maintenance, because every change happens twice forever. A shared codebase is substantially less, at the cost of some polish and occasional platform-specific work. And launching on one platform first is the cheapest of all, at the cost of half your potential audience for a while.
Which is right depends on something you can check rather than guess: look at what your existing customers actually use. Most businesses discover their audience skews heavily to one platform, and launching there first buys months. If you genuinely do not know, that is an argument for a web version first, which reaches everyone immediately and tells you the answer from real usage rather than assumption.
Not for you if
If you take one number from this, take the ratio rather than the range: in most projects we see, the building is about half the elapsed time. Plan the other half deliberately and the date stops being a surprise.