How Many Stages Does the Mobile App Development Process Have?
There are five stages: discovery, design, development, testing and store release. The stages don't run in sequence but partly on top of one another. What sets the total schedule is not the number of stages but the number of decisions taken in each. The mobile app development process is stretched by indecision, not by scope. A single approval left waiting can eat two weeks.
Thinking of the stages as a straight line is misleading. Development starts before the design is finished, and testing runs while development is still going. That overlap shortens the schedule, but on one condition: that decisions come out on time.
The sequence below is the order we run. Throughout the process, the development team and your side look at the same board.
- Discovery — the problem, the user, the screen inventory.
- Design — the flow, the screens and the state designs.
- Development — building in two-week sprints.
- Testing — inside the sprints, not a separate block.
- Store release — review, with a margin for corrections.
What Really Stretches the Schedule?
Not the code — the decision left waiting. A screen waiting for approval can waste a two-week sprint all on its own. That is why we identify the person who will decide in the first session. A point of contact without authority is the most expensive source of delay in the development process.
How Long Does the Discovery and Scope Stage Take?
This stage usually takes one to two weeks. In that time the problem definition, the user flow and the screen inventory come out. Short as it looks, this stage shortens all the ones that follow. Throughout the development process, this is the document we come back to most. Skip it and the design stage comfortably doubles.
We don't draw screens in the discovery session. We talk about how the work runs today, where it gets stuck and who takes which decision. The output is a single page: the problem, the user, how often it is used, the screens you cannot do without, and the external services.
If you bring that page to the meeting yourself, the stage comes down to three days. We listed the questions that need answering one by one in the questions to ask before commissioning an app article.
People who want to shorten discovery usually try to skip it altogether. The result is always the same: the design stage is spent asking the questions discovery never asked. Trying to win time on the development side means losing it right at the start.
What Does the Discovery Output Look Like?
Not a thick specification — a single page. Long documents don't get read, so they slow decisions down. A single page stays in everyone's head and becomes the shared language for the whole mobile app development process.
What Gets Produced in the Design Stage?
This stage gives three outputs: the flow diagram, the screen designs and the state designs. The third is forgotten in most quotes, yet it is the one that most determines the schedule. If the empty list, the broken connection and the timeout screens aren't drawn here, the work slides into development. Solving it there takes longer. The job of design isn't to make the screen prettier; it is to take the decision in advance.
The typical length is two to four weeks. It stretches not as the number of screens grows but as the number of states grows. A product with ten screens but four states each takes longer than a twenty-screen catalogue.
We took up which principles interface decisions rest on in the interface design principles article. When the design is finished, there should be no undrawn screen left for development.
Skipping the state designs hits the schedule in two places at once. First the developer makes an assumption, then you don't like the assumption. Having the development team design screens in the middle of the process makes for a route that is both slow and inconsistent.
How Many Rounds Do Approvals Run To?
Two rounds is normal; a third round is a warning. If it is going round more than three times, the problem isn't in the design but in a decision left unmade at discovery. At that point we go back a step.
How Do the Development and Testing Stages Proceed?
They proceed in sprints two weeks long. At the end of each sprint a working build reaches you and we take your comments. Testing isn't a separate stage; it sits inside every sprint. When the development process runs to that rhythm, surprises are spread through the middle rather than piling up at the end. A surprise saved for the end is always the more expensive one.
At the end of every iteration we send a build you can install on your own device. Seeing it on screen is different from reading it in a document; your comments sharpen at that point too. The typical length runs from six to sixteen weeks depending on scope.
If work close to the hardware is needed, the schedule widens. We handle requirements such as the camera, sensors and background location separately on the iOS and Android sides of the build. We weighed the choice of architecture up in the native or cross-platform article.
Why Isn't Testing a Separate Block?
Testing left to the end gathers the faults at the most expensive moment. Spread through every sprint, a fault is fixed the day it appears. That arrangement is the habit that saves the most time within the mobile app development process.
Why Does the Store Release Take Longer Than Expected?
The review is not a technical exam, it is a rules check. Apple and Google look separately at the privacy policy, the permission rationales and the account deletion flow. Being rejected on the first submission is ordinary. That is why we put a week's margin for release into the development process schedule. Teams that leave no margin postpone the launch date twice.
What Are the Most Frequent Reasons for Rejection?
The release review usually takes a few days, but if a rejection comes back the clock starts again. The most frequent reasons for rejection are surprisingly simple: a missing privacy policy, a permission requested without a rationale, no route to deleting an account.
Prepare those as development begins and release day doesn't turn into a surprise. The store listing itself is a separate piece of work; the title, the images and the description have a direct effect on the download rate.
The two stores don't move to the same rhythm either. One may answer the same day while the other keeps you waiting several; that is why we talk about a release week rather than a single release date. Marking that week in the development process plan makes the launch communications easier too. Reasons for rejection aren't guesswork but written rules; the App Store Review Guidelines list them all.
“For certain developer accounts, we’ll take more time to thoroughly review your app to help better protect users. This may result in review times of up to seven days or longer in exceptional cases.”
— Play Console Help, Publish your app
Let's Work Out Your Schedule Together
A schedule only becomes realistic the moment the scope is clear. In the meeting we write down the stages, the approval points and who decides when, together. What you are left with is not an estimated duration but a dated plan. When the mobile app development process is set up that way, the source of any delay is visible from the start. Delay usually comes not from the code but from an approval left waiting.
While we draw up the plan we also discuss, at the same table, which item moves the budget; we opened the two up separately in the app cost article. Our mobile app service page is always open if you'd like to look through it.
Which Three Dates Carry the Schedule?
When we draw up the plan we mark three dates. The day the discovery output is approved, the day the design is locked, and the day of the first submission to the store. If those three hold, the rest holds of its own accord. Within the mobile app development process, the date that slips most often is the second. When the design lock is late, everything slips with it. To protect that lock we tie the approval window to two working days. It looks like a small rule, but on its own it keeps the schedule standing.
Typical length per stage and what stretches the schedule
A typical mobile app project takes about 9–24 weeks from discovery to store release. The longest slice is development, at 6–16 weeks. Testing isn't a separate stage; it runs inside the sprints. Uncertainty over who decides and scope changing mid-sprint stretch the schedule most often. At release, gaps in privacy and permissions cause waiting.
| Stage | Typical length | What stretches it |
|---|---|---|
| Discovery and scope | 1–2 weeks | Uncertainty over who decides |
| Design | 2–4 weeks | Skipping the state designs |
| Development | 6–16 weeks | Scope changing mid-sprint |
| Testing | Inside the sprints | Leaving it to the end |
| Store release | 3 days – 2 weeks | Gaps in privacy and permissions |
Stage Count or Decision Speed: What Sets the Schedule?
The mobile app development process has five stages, but the schedule isn't set by the number of stages. How quickly decisions come out matters more than how fast the code gets written; the plan has to be built on that fact.