Building a mobile app: the steps, from scoping to store release

We are often asked "where do we start?". The answer comes down to seven steps, always the same ones, whether the app is an internal tool for twenty technicians or a consumer product. What changes from one project to the next is how long each step takes and how many decisions need making.

This article gives the overview: the order of the steps, what each one produces, how long it takes and, above all, what you need to bring to each one. For the detail of each step, we point to our dedicated articles rather than repeating them here.

The seven steps in one table

The durations below are our orders of magnitude per step. Design and development overlap: the first approved screens go into development while the next ones are being drawn. The totals match our usual timelines.

In terms of workload, an MVP typically represents 30 to 60 person-days, a full app 120 to 200. For a business platform or a marketplace, allow 5 to 8 months and 250 to 450 person-days.

Step 1: the idea, framed as a problem

Before talking about screens, you need to be able to answer three questions in one sentence each. What problem does the app solve? For whom, exactly? What do these people do today instead?

The third question is the most useful. If the answer is "nothing, they don't care", the project is fragile. If the answer is "a spreadsheet, phone calls and a lot of re-keying", you have a real need, and a baseline for measuring the gain.

What you bring: those three answers, an idea of the budget you are prepared to commit and, if possible, a few potential users to talk to. A budget envelope, even a broad one, saves a lot of time: it tells you straight away whether you are heading for an MVP or a full version. Our guide to the cost of a mobile app details the budget tiers.

Step 2: scoping, where the timeline is decided

Scoping turns the idea into a scope that can be costed. It produces a main user journey, a prioritised feature list, the technical choices, the integrations required (payment, ERP, CRM, existing APIs) and a schedule.

It is the shortest step and the one that weighs most on everything after it. A fuzzy scope at this stage is paid for in weeks during development. Two decisions are made here:

• The scope of the first version. Most projects are better off starting with an MVP. Our method for cutting the scope of an MVP explains how to go from forty features to six without damaging the product.
• The technology. On an iOS + Android project, cross-platform (React Native, Flutter) saves 30 to 40% compared with two native apps. Native (Swift, Kotlin) remains relevant for very hardware-heavy uses: sensors, Bluetooth, advanced video processing. We go through the trade-off in React Native, Flutter or native.

The scoping deliverable is a short, living requirements document. The requirements template we use shows what it should contain and what is pointless to include.

What you bring: one person who makes the calls (not a committee), the measurable goals the app has to reach, the known constraints (dates, regulation, health data, hosting) and access to, or documentation for, the systems the app needs to talk to.

Step 3: design, from journey to screens

Design starts with wireframes (the sequence of screens, without colour), then moves on to visual mock-ups and a clickable prototype. The prototype lets a few users test the main journey before a single line of code is written. Fixing a screen at this stage takes an hour; fixing it once developed takes days.

Two points deserve attention from this step onwards: onboarding, which decides a large part of retention, and the "empty" and "error" states that nobody draws spontaneously and that everyone will see.

What you bring: your brand guidelines (logo, colours, typefaces), real content rather than placeholder text, and grouped, prompt feedback. A round of mock-ups that waits a week for sign-off pushes the whole schedule back by a week.

Step 4: development, in short iterations

We develop in iterations of one to two weeks. Each one ends with a demo on a phone: you see the app progress, install it on your own device, and correct the course while it is still cheap to do so.

This pace has a direct consequence: changes of direction are possible, but they are negotiated at constant budget. A feature that comes in replaces another one, or moves the date. This is the rule that stops a 6-week MVP from lasting 14.

Development covers the app itself, but also the back end (database, API, back office), notifications, analytics and the integrations decided at scoping. Integrations with third-party systems are the main source of surprises: a badly documented API or delayed access can block an entire iteration.

What you bring: your attendance at demos, written feedback within 48 hours, access to the APIs and test environments of the tools to be connected, and realistic test data.

Step 5: acceptance testing, on real phones

Acceptance testing checks that the app does what was agreed, on your users' devices and in their real conditions: weak network, older phone, dark mode, enlarged text, interruption by a call. Part of the testing is automated and runs continuously during development; the final acceptance round remains human.

Defects are ranked by severity. Blocking ones are fixed before release; minor ones can go into the first update. This distinction avoids postponing a launch over a three-pixel margin.

What you bring: testers who know the business, a few devices representative of your audience (not just management's latest iPhone), test scenarios written from your real cases, and a proofread of every piece of text in the app.

Step 6: release on the App Store and Google Play

Releasing is not a single click. You need to prepare the store listings (name, description, screenshots, keywords), an online privacy policy, the declarations about the data collected and a demo account for the review teams.

The delays are known and need to be scheduled:

• Apple says it reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. The risk is not the length of the review, it is a rejection followed by a resubmission.
• Google Play requires personal accounts created after 13 November 2023 to run a closed test with at least 12 testers opted in for 14 consecutive days before applying for production access, whose review usually takes seven days or less. As Google publishes it, this rule targets personal accounts: one more reason to open the account in the company's name.

On fees, the Apple Developer Program costs 99 USD per membership year and Google Play charges a one-off 25 USD. The most common rejection reasons, and how to avoid them, are covered in our article on App Store and Google Play rejections.

What you bring: developer accounts opened in the company's name (step 2), the URL of your privacy policy, sign-off on the listing copy and visuals, and the legal information the stores ask for.

Step 7: measure, fix, maintain

Launch opens the most instructive period of the project. For the first four to eight weeks, three figures are enough: how many people complete the main journey, how many come back the following week, and where the others drop out. These figures decide version 2, not the list of ideas set aside at scoping.

In parallel, the app has to keep up with new versions of iOS and Android, store requirements and updates to its dependencies. An app that is no longer touched ends up being removed or no longer working on recent phones. Allow 15 to 20% of the initial cost per year; the breakdown of that budget is in our article on what maintenance really costs.

What you bring: measurable goals for tracking, someone who reads user feedback and store reviews, and an annual budget planned from the outset rather than discovered at the first incident.

The three traps that stretch a project

The decision-maker who can't be found. When every trade-off goes through three people who are never available at the same time, a one-week iteration lasts two. The schedule of a mobile project depends as much on your response times as on the technical team's.

The scope that grows bit by bit. "Just one more field", "while we're at it". Each addition costs little; together they cost a month. The only remedy that holds is the swap at constant budget.

The stores forgotten until the end. Accounts not opened, a D-U-N-S Number still to request, no privacy policy, a Google closed test still to launch: so many incompressible delays discovered just as the app is ready. Handled at scoping, they run in parallel with development and cost nothing.

A mobile project keeps to its timeline when decisions are made at the right moment: the scope at scoping, the screens at design, the priorities at every demo.

Going further: our mobile app development page explains how we run these seven steps, from the first scoping workshop to store release.

Sources

• Apple Developer, App Review: review times for submissions (at least 50% in under 24 hours, 90% in under 48 hours).
• Apple Developer, Enrollment: cost of the Apple Developer Program (99 USD per year) and D-U-N-S Number requirement for organisations.
• Apple Developer, D-U-N-S Number: time to obtain the number (up to 5 business days) and for Apple to receive it (up to 2 business days).
• Google Play Console Help, App testing requirements for new personal developer accounts: closed test with 12 testers for 14 days, production access review usually seven days or less.
• Google Play Console Help, Get started with Play Console: one-off registration fee of 25 USD.