Key takeaways
- Count from the first conversation to the app stores, not from the first line of code: much of the time goes on decisions, content, accounts and review.
- User roles and outside systems move an app into a longer range faster than extra screens do.
- Much of the calendar is waiting: feedback, content, logins to outside systems and store accounts. Put your own tasks in the plan with dates.
- Start the Apple and Google developer accounts in week one. A company needs a D-U-N-S Number for Apple, and new personal Google Play accounts must run a 14-day closed test.
- The quickest way to shorten a timeline is a smaller first version, not a bigger team.
Ask three teams how long a new app will take and the answers sound alike: three months, six months, “it depends”. The useful answer is a range for your kind of app, plus an honest look at where the weeks go. Much of that time isn’t spent writing code: it goes on decisions, content, outside accounts and store review. The ranges by app type come first, then each phase, the hidden calendar most plans leave out, and a week-by-week plan you can hold a team to.
How long does each kind of app take?
Each kind of app has its own range, from about two months for a simple app to a year or more for a complex platform, and the jump between them comes from user roles, integrations and rules, not from the number of screens. The table below gives illustrative ranges from first workshop to the app stores, with what each kind usually includes.
Two things move an app from one column to the next faster than anything else: a second or third type of user (a customer app plus a staff app plus an admin panel is three products, not one), and an outside system that has to work on day one, such as a payment gateway, a hospital’s records or a company’s ERP. If your app has either, plan for the next column along.
Working to a date?
Tell us what the app must do and when it has to launch, and we’ll talk through what fits in that time.
What happens in each phase?
An app moves through five phases: discovery, design, build, testing and launch, and on a well-run project they overlap rather than queue behind each other.
- Discovery turns the idea into a written scope: who the users are, what the first version must do, what it connects to and what waits for later. On a small app it takes days; on a platform it takes weeks. Skipping it doesn’t save the time, it moves it into the build, where each unanswered question costs more.
- Design turns the scope into screens you can click through. The core flow is designed first, so building can start on it while the less critical screens are still being drawn.
- Build is the backend, the admin panel and the app itself, delivered in short releases you can try. It is the longest phase, and the one most quotes describe in detail.
- Testing runs through the build, but needs its own block at the end: testing on real phones, including a low-cost Android phone, a beta with real users and fixing what they find.
- Launch is the store listings, the submissions, the review and the release. It is short, but it has fixed waits that no team can compress, which the next section covers.
Where does the time really go?
Much of the time goes to waiting for decisions, content and access, not to coding. If a four-month project has a round of feedback every week, and each round comes back two working days late, that alone can add more than a month, and no estimate will have included it. These are the items that stretch real calendars, and what to do about each one.
None of this is a reason to blame the client or the team. It is a reason to put the client’s tasks in the plan with dates, the same way the team’s tasks are, and to review both every week.
What do Apple and Google add to the timeline?
App review itself is usually quick, while the store accounts and Google Play’s testing rule for new personal accounts can take weeks, so start them in the first week of the project. Here is what Apple and Google say, checked 20 October 2026:
- Apple’s review. Apple says App Review typically reviews “at least 50% of submissions in less than 24 hours and 90% in less than 48 hours”, and that an incomplete submission can be delayed or rejected (Apple App Review). A rejection means fixing the issue and submitting again, so plan a few days of slack.
- Apple’s company account. Companies enrolling in the Apple Developer Program need a D-U-N-S Number; government bodies are exempt. Apple asks you to allow up to 5 business days to get one from Dun & Bradstreet, and up to 2 more business days for Apple to receive it, before you can enrol (Apple D-U-N-S). Apple also checks that the person enrolling can sign for the company, that the website works and that the email address uses the company’s domain (Apple enrolment).
- Google Play’s testing rule. Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers, opted in continuously for at least 14 days, before they can apply for production access. Google says the review of that application “usually takes seven days or less, but can occasionally take longer” (Google Play Console Help).
- Google Play’s review. Google says updates are processed “as soon as possible”, and that apps from some developer accounts can get extended reviews of up to 7 days, or longer in exceptional cases (Google Play Console Help).
Publish under your company’s own developer accounts, set up by you, so the app and its listing stay yours whoever builds it. Our guide to who owns an app’s source code covers the accounts to hold.
What does an honest week-by-week plan look like?
An honest plan shows what you will see at the end of each phase, what you have to supply and when, and where the fixed waits sit. The one below is illustrative: an MVP-sized app with one main user flow, an admin panel and analytics, built cross-platform for both stores.
Weeks 1–2: Discovery
Workshops, the feature cut and a written scope. Open both developer accounts and start any outside approvals.
Weeks 2–4: Design
The core flow as a clickable prototype first, then the rest of the screens. You review on a fixed day each week.
Weeks 4–11: Build
Backend, admin panel and app in weekly or fortnightly releases you can try on your phone. Your content goes in as it arrives.
Weeks 11–13: Beta and fixes
A closed test with real users on real phones, including a low-cost Android one. Fix what they find.
Weeks 13–14: Launch
Store listings, submissions and review, with a few days of slack for a rejection. Release, then watch the first users.
An illustrative plan for an MVP-sized app, built cross-platform for both stores. Your weeks will differ; what matters is that every phase ends in something you can check.
Ask any team you talk to for its version of this plan. What you are looking for:
- Something you can try every week or two, from the first build onwards, not one big reveal near the end.
- Your tasks with dates on them: the content, the decisions, the logins to outside systems, the beta testers.
- The store accounts and testing rules in week one, not in the last fortnight.
- A test block with real users before launch, with time left to fix what they find.
How long does an MVP take?
Plan for about three to four months from first workshop to launch for an MVP: two to three weeks to agree the scope, then eight to fourteen weeks to design, build, test and launch the first version. That is the shape of our own MVP Launch package, which runs 8–14 weeks, often after a 2–3 week Discovery Sprint.
The range depends far more on what goes into the first version than on how fast anyone codes. An MVP that proves one thing, with one core flow and an admin panel, fits the range. An MVP that tries to launch the full product, with every role and every integration, is a mid-sized app with a smaller name, and it takes as long as one. The quickest way to shorten an MVP is to move features to version two, which our MVP development page walks through.
What actually speeds it up?
Fewer decisions left open speeds an app up more than more developers do: a settled scope, quick feedback and a small first version. Adding people to a late project rarely helps, because new people need time to learn the code and the plan. These are the changes that do help.
How a team works matters as much as its size. At Tailwebs, 50+ people work with 200+ AI agents in our delivery process, which lets us deliver up to 50% faster and put more checks on every release. The agents speed up the work; the scope still decides the date.
How do you set a launch date you can keep?
Work back from the date to a scope that fits it, rather than forward from a feature list to whatever date it produces. Decide what the launch has to achieve: an investor demo, a pilot with one customer, a public launch. Then cut the first version to what that needs, start the store accounts in week one, and keep two to three weeks of slack before the date for testing and review.
If the date can’t move, the scope has to be the thing that moves, so agree now which features are first to go if the plan slips. How the contract handles that matters too; our guide to fixed price or time and materials shows what happens to the timeline under each. To see how we plan, release and review a build week by week, read how a project runs, or tell us about your app on our mobile app development page.