Insights · Planning · 6 May 2026
How long does it take to build an app?
Timelines are the second question on every first call, right after cost. The honest answer has a range, and you control most of what decides where you land in it.
"Six weeks," said the first agency. "Nine months," said the second. The founder asking had one idea and two answers separated by a factor of six, which is the moment most people give up on getting a straight answer at all.
Both numbers were probably honest. They were answers to different questions, because "how long does it take to build an app" is really three questions wearing one sentence: how long until something runs, how long until strangers can use it, and how long until it is the polished thing you imagine. Separate them and the fog clears.
The realistic ranges
For a focused first version, from an agreed brief to a store listing: a native mobile app usually takes six to twelve weeks. A web application of similar ambition runs four to ten. A marketing website takes two to six. These ranges assume one clear decision maker, a scope that is written down, and a team that starts when it says it will.
Ranges outside these bounds carry information. A promise of a full app in two weeks means the scope has been cut somewhere you have not noticed yet. A first version quoted at nine months means you are being sold version three before version one has met a user.
What actually moves the schedule
Scope, counted properly. The number that matters is not screens, it is the features that must be correct on day one. Each one carries design, engineering, testing, and its own failure cases. The failure cases are the hidden half of every schedule: a sign in screen is a day, but sign in with password reset, expired links, and locked accounts is a week.
Decision speed. This is the factor nobody budgets. A build that waits three days for every answer runs three times longer than the calendar says it should, and no team can engineer around a silent decision maker. When we estimate a project, we are estimating the client's calendar as much as our own.
Platform count. One platform first cuts the surface in half and doubles the speed of learning. The second platform goes faster afterwards, because the first one already answered the expensive questions.
Integrations. Anything that talks to another company's system, payments, calendars, messaging, sync, adds real time, because the other system's rules and failures become your project's rules and failures.
A calendar you can sanity check
Here is the shape of a healthy twelve week native build, usable as a ruler against any plan you are shown. Week one: something installs and the main loop exists in skeleton form. Week three: navigation settled, data flowing. Weeks four to eight: the loop gets good, features land behind flags, demos every Friday. Week eight: the scope cut, on schedule. Weeks nine to twelve: store work, instrumentation, launch.
If a proposed plan has nothing runnable before week six, the risk is stacked at the end, exactly where it is most expensive to discover. Ask why.
How to keep your own build on time
Write the one page brief and the version two list before the clock starts, so cutting scope later is a plan rather than an argument. Ask for working software weekly, because slippage visible in week two costs a conversation and slippage discovered in week ten costs a quarter. Fix the deadline and flex the scope, never the reverse: a smaller app that ships on the agreed date beats the full plan arriving a season late, and it starts teaching you about your users months earlier.
And when someone quotes you a timeline, ask which of the three questions they are answering. The teams worth hiring will know exactly what you mean.