The mobile app development process,
in 7 stages

Discovery answers the question that decides everything else: what problem are we solving, for whom, and how will we know it worked? The team interviews target users, studies competitors and their reviews, maps the riskiest assumptions and writes a prioritised scope.

• Five to ten interviews with people who have the problem
• A competitor review, including their app-store reviews
• One sentence describing the job the app does for its user
• A ranked feature list with a clear cut-off for version one
• A single success metric, such as weekly active users completing the core task

Skipping discovery is the most expensive saving in software. It is how teams build the wrong thing very efficiently.

UX design decides how the app works — the flows, screens and steps. UI design decides how it looks — layout, type, colour, motion. Good teams move from rough wireframes to a clickable prototype and test it with real users before development starts.

Testing with as few as five users uncovers most usability problems, according to Nielsen Norman Group's long-standing research¹. Changing a prototype takes minutes; changing built code takes days. Design should also follow each platform's conventions — Apple's Human Interface Guidelines² and Google's Material Design³ — so the app feels familiar from the first tap.

With designs agreed, engineers choose how to build it: native or cross-platform, the backend and database, third-party services (payments, maps, login, push), the data model and how the app will scale. This is also where security and data-protection decisions get made, not bolted on later.

Insist on: a short written architecture note, a list of every third-party service with its cost, and accounts created in your company's name.

Development usually runs in two-week sprints. Each sprint ends with a demo of working software on real devices, so you can see progress and change course. Mobile apps, backend and admin panel are built in parallel.

This way of working follows the principles of agile development, which favour working software and responding to change over following a fixed plan⁶.

Testing runs through every sprint, then intensifies before launch. It covers:

• Functional testing — does every feature do what it should, including edge cases?
• Device testing — on the low-cost Android phones many users carry, not only flagships.
• Performance — start-up time, smoothness, battery and data use.
• Security — how data, passwords and keys are handled.
• Beta testing — real users on test builds through Google Play testing tracks and Apple's TestFlight⁵.

New Google Play personal developer accounts must run a closed test with at least 12 testers for 14 continuous days before applying for production access⁴. Treat it as useful feedback, not a box to tick.

Launch is more than pressing "publish". It includes store listings (screenshots, description, keywords), privacy and data-safety declarations, age ratings, store review, and usually a staged rollout to a small percentage of users first so problems surface before everyone has the update.

Our step-by-step guides cover publishing on Google Play and publishing on the App Store.

This is where good apps become great ones. The team watches where users drop off, which features they ignore, why they leave reviews and which crashes they hit — then feeds that back into discovery for the next version.

• An analytics plan for the core funnel, set up before launch
• Crash reporting and performance monitoring
• A weekly look at retention: of the users who joined, how many came back?
• Regular user interviews, especially with people who stopped using the app
• A release rhythm: small, frequent updates beat rare big ones

Stage seven is also where behavioral UX work pays off most: understanding why users hesitate, stall and leave. That is exactly what a mobile app UX audit looks for.

Wireframe — a simple layout of a screen without visual design. Prototype — a clickable mock-up used to test flows. Sprint — a fixed work period, usually two weeks, ending in a demo. Release candidate — a build believed ready for launch. Staged rollout — releasing to a percentage of users first. Agile — an approach that builds software in small increments and adapts to feedback.