Building an app takes one developer roughly 6 to 13 weeks for a web app with accounts, payments and an admin area, about 6 to 12 weeks for a mobile app on one platform, and 7 to 15 weeks for iOS and Android together. Those are weeks of effort. The calendar time is always longer, because feedback, decisions, design and app store review add weeks that no estimate of the work itself includes.
If you were hoping for one number, there is not one. What you can get is a range built from the pieces of your project, and a clear list of what stretches it.
Effort first: the usual ranges
These come from the same ranges our project cost estimator uses, counted in developer-days and rounded to weeks of five days. They assume one competent developer and an off-the-shelf design kit.
| What you are building | Developer-days | Roughly |
|---|---|---|
| Landing page or marketing site | 6 to 15 | 1 to 3 weeks |
| Web app with accounts, payments and an admin area | 29 to 63 | 6 to 13 weeks |
| Mobile app, one platform, with accounts and notifications | 28 to 58 | 6 to 12 weeks |
| Mobile app, iOS and Android, same features | 36 to 73 | 7 to 15 weeks |
Each row includes three to seven days for setup, testing and launch, which is the line most quotes forget.
Two things widen the range fast. Design that still needs doing adds roughly six to fourteen days. And every extra feature has its own cost: realtime chat is five to twelve days on its own, AI features four to twelve, a second language three to seven.
Why the calendar runs longer than the effort
Eight weeks of work almost never finishes eight weeks after it starts. The gaps come from places outside the code:
- Your decisions. Every question the developer sends waits for your answer. A one-day reply instead of a one-hour reply, across a whole project, adds weeks.
- Feedback rounds. You will see the first working version and want changes. That is healthy, and it is time.
- Content. Copy, images, product data, legal pages. Someone has to produce them, and it is rarely the developer.
- Third parties. Payment provider approval, API access, a design arriving late.
- Part-time reality. A freelancer on two projects is not giving you five days a week. Ask.
So when you plan, keep two numbers: the effort, and the date. Size the gap between them from the list above. If content is not ready and you reply to questions once a day, it is not a small gap.
The app stores add their own waits
A website goes live when you press deploy. An app goes live when a store approves it, and both stores add time a web project never has.
- Apple. Apple says App Review typically reviews at least half of submissions in under 24 hours and 90% in under 48 hours. A rejection means a fix and a resubmission, so plan for at least one. (Apple App Review)
- Google Play. Google's own help pages say review can take up to seven days, or longer in exceptional cases, for some developer accounts, and suggest leaving at least a week of buffer before a planned launch. (Play Console Help)
All three were checked in October 2026.
What makes it take longer
The estimator applies these as multipliers, and they are worth knowing before you talk to anyone:
- Only an idea, no written spec. Someone has to turn it into a plan before building. Add around 15%.
- An existing codebase to extend. Reading someone else's code is real work, and nobody knows what is in it until it is read. Add around 25%.
- Regulated data. Health, finance, children's data. Add around 25% for the extra care.
- Real traffic from day one. Building for scale before you have users. Add around 15%.
What makes it faster
- Finished designs and a clear spec. Saves time on every screen, because nobody is guessing.
- One platform first. Ship iOS or Android or the web, learn, then add the second.
- Cutting scope, not corners. An admin area can often be a spreadsheet for the first three months.
- Fast answers. The cheapest way to save a week is to reply to questions the same day.
A written project brief does more for your timeline than any amount of pushing on a deadline, because a developer who understands the job does not stop to ask.
How to get a real timeline for your project
- Run your project through the estimator and keep the line-by-line breakdown.
- Write a brief: what exists, what "done" means, real constraints, your budget.
- Ask two or three developers for an estimate against the same lines.
- Where their numbers differ from yours, ask why. The gap is nearly always a piece one of you forgot.
- Agree a first slice of one to two weeks with its own deadline, and see how the real pace compares.
That fifth step tells you more than any estimate. After two weeks you know how fast this particular person, on this particular project, actually moves, and the rest of the timeline stops being a guess. The money side of the same question is in how much does it cost to build an MVP.