Why it helps to know the stages
From outside, app development can look like a long silence followed by a product. Projects run that way do exist, and they are the ones that surprise their owners. A well-run project is a sequence of short stages, each producing something the client can inspect, with decisions made in the open.
The names vary between companies. The substance should not. Use the table below to read any proposal: for each stage, look for what you will receive and what you will be asked to approve.
The six stages and their deliverables
| Stage | What happens | What you receive | Your decision |
|---|---|---|---|
| Discovery | Users, workflows, scope and risks are worked out | Scope for the first release, estimate, plan | Approve scope and budget |
| Design | Flows and screens are designed and tested | Clickable prototype, design files, design rules | Approve the experience before it is built |
| Technical setup | Architecture, accounts, repository and build pipeline are prepared | Access to the repository, a first installable build | Confirm accounts are in your organization's name |
| Development | Features are built in short cycles | A new test build and a short report each cycle | Feedback and priorities for the next cycle |
| Testing | The whole app is checked on real devices | Test results, list of known issues, release candidate | Accept the release |
| Release | Store listings are prepared and the app is submitted | Live app, store assets, release notes | Approve the listing and launch date |
Support after launch is sometimes called a seventh stage. It has no end date, so it is better treated as a separate agreement that begins on launch day.
Discovery and design: decide before you build
Discovery turns an idea into a first release that can be estimated. It should name the users, describe what each of them does in the app, list the systems the app must talk to and separate what is needed at launch from what can wait. If you are preparing for one, our mobile app scope planner helps you arrive with your own answers.
Design then makes the scope visible. A clickable prototype lets you, and a few real users, walk through the main tasks on a phone before any code exists. Changes cost little at this point and a great deal later. Expect to see the awkward screens as well as the attractive ones: empty states, errors, slow connections, permission requests and what the app does when a notification is tapped.
Setup and development: progress you can install
Before features are built, the team sets up the foundations: the code repository, the build pipeline that produces installable versions, the test and production environments, and the developer accounts with Apple and Google. Ask for those accounts to be opened by your organization, with the development company invited as a user. Verification of an organization can take time, so start early.
- 01
Work is planned in short cycles
Each cycle has a small set of features agreed with you, chosen so that the app is usable a little further each time.
- 02
Each cycle ends with a build
You receive a version to install through the test channels the stores provide, such as Apple's TestFlight or a testing track on Google Play.
- 03
You try it and respond
A few minutes with each build, on your own phone, catches misunderstandings while they are cheap to correct.
- 04
Scope changes are handled openly
New ideas are welcome. Each is estimated and either swapped for something else or added to the budget, in writing.
Testing and release: the last stretch is real work
Testing runs throughout development, and a dedicated pass comes before release. The app is checked on a range of real phones and operating system versions, on poor connections, with permissions refused, and through every payment and sign-in route. You should receive a short record of what was tested and a list of known issues with a decision on each.
Release is a stage of its own. Store listings need screenshots, descriptions, privacy declarations and an age rating. Both stores review apps before publishing, review times vary and a submission can be sent back with questions. A sensible plan leaves room for that, avoids announcing a launch date that depends on a first-time approval and prepares a staged rollout where the store allows one.
A worked example
A loyalty app for a restaurant group
This example is invented to show what the client sees at each stage. A restaurant group commissions an app for ordering ahead and collecting points.
- DiscoveryThe scope for the first release is ordering, payment and a points balance. Table booking and gift cards are written down as later phases. The point-of-sale system is identified as the main risk.
- DesignA prototype is tried by eight regular customers in one branch. Most hesitate at the pickup time screen, which is redesigned before development starts.
- DevelopmentThe operations manager installs a build every second Friday. In the third cycle she notices that modifiers such as extra toppings are missing from orders, and the fix is scheduled for the next cycle.
- TestingOrders are placed against the real point-of-sale system in one branch after closing time. Two issues are fixed, and one cosmetic issue is accepted for a later update.
- ReleaseThe first store submission is returned with a question about account deletion. The team adds the missing option and resubmits. Launch is announced only after approval.
Nothing in this project came as a surprise to its owner, because each stage ended with something she could try. The single store rejection cost a few days that the plan had already allowed for.
How to tell whether a project is healthy
Healthy signs
- A new build arrives on a regular rhythm
- You can name what was finished in the last cycle
- Problems are raised early, with options
- Changes to scope are written down with their cost
- You have access to the repository and the accounts
Warning signs
- Weeks pass with reports but nothing to install
- Progress is described only as a percentage
- Testing is planned entirely for the end
- The app can only be shown on the developer's device
- Store accounts are in the development company's name
Deliverables checklist
Mobile app deliverables checklist
0 of 10 checkedWhat to do next
Hold any proposal you have received against the table of stages, and mark where a deliverable or a decision is missing. Those gaps are your questions for the next call. Our guide to writing a mobile app requirements document will help with the stage before all of these.
Our mobile app development page describes how we run these stages. Tell us about your app and we will outline what the first two would produce for you.
Common questions
How long does each stage of app development take?
It depends on the size of the first release, the number of integrations and how quickly decisions are made on your side, so an honest answer needs your scope. As a pattern, discovery and design are short compared with development, and release needs more time than people expect. Ask for a plan by stage with the assumptions behind it.
Can design and development overlap?
Yes, and they often do once the main flows are approved. Designers move ahead to later features while developers build the first ones. What should not be skipped is approval of the core experience before it is built, because rebuilding a finished flow costs far more than revising a prototype.
What should we hold when the project ends?
The source code in a repository you control, the design files, the developer accounts and store listings, access to hosting and third-party services, and documentation for building and releasing the app. Ownership and licensing terms are defined in the project agreement, which is where to confirm how custom code and licensed components are treated.
Should payment follow the stages?
Linking payments to stages or to regular cycles keeps both sides honest, provided each payment relates to something you have received and can inspect. Be cautious of a schedule where most of the money is due before the first installable build, or where the final payment is so large that the company carries all the risk.
What happens after the app is released?
Operating systems change every year, devices are added, users report issues and you will want improvements. Plan for monitoring of crashes and reviews, regular maintenance releases and a budget for new features. An app that receives no updates gradually stops working well, and the stores may eventually flag it.