The mobile app development process: what to review at each stage

A business app moves through discovery, design, technical validation, development, testing, release and ongoing support. The useful question at each stage is what evidence the business needs before committing to the next one.

Agree those review points with your developer at the start. They help you spot misunderstandings while a change is still manageable, rather than waiting for a finished app to discover that a business rule was interpreted differently.

Discovery: a scope you can explain

Begin with the users, the task and the information it depends on. List the systems involved and who is authorised to make each decision. Include administrative work: approving a request, correcting a record or helping someone regain access.

The output should be a first-release scope, assumptions, exclusions and open questions. If the budget depends on an integration being available, that dependency should be visible. Use our app brief worksheet to prepare.

Prototype: test the journey

A prototype helps people try the sequence before the complete system exists. Ask a likely user to complete a realistic task without coaching. Watch where they hesitate, what information they look for and whether the completion message makes sense.

Review the important alternatives too. What does a person see when there are no available times, a request is declined or required information is missing? Agree the language and next steps. A prototype confirms design decisions; a technical proof is still needed for uncertain device features or connections.

Technical proof: check the dependencies

Test the part that could change the feasibility or price. That might be an existing system's API, a payment provider, an offline requirement or a device capability. Use test accounts and demo data where possible.

Ask for a clear result: what worked, on which devices or test systems, what remains uncertain and how the scope changes if a dependency is unavailable. Our device capability checklist is useful when comparing a web app with an installed app.

Development: review working sections

Review complete pieces of a journey as they become available. Seeing a customer request reach the staff review screen is more informative than seeing several disconnected screens marked complete.

Cloudfusion's public ViaVia case study shows trip information, trust context, requests and private chat as parts of one community travel product. Use the same kind of joined-up review for your own app: check what the person sees, what the action changes and what happens next.

Record agreed changes and their effect on cost or timing. A new approval role may sound small but can affect permissions, notifications, reports and testing.

Acceptance: test the uncomfortable cases

Prepare acceptance checks alongside the scope, then run them against the release candidate. Include:

• A complete main journey with realistic demo data.
• Different user roles, including attempts to access records they should not see.
• Repeated actions, interrupted connections, expired sessions and unavailable external services.
• Supported phones and browsers, readable text, keyboard access and usable error messages.
• Staff tasks such as correcting an entry, handling a cancellation and finding a failed integration.

Log issues with the steps to reproduce them and their business impact. Decide which must be resolved before release and which can safely wait. A successful demonstration is one check, rather than the entire acceptance process.

Release and handover

Before launch, confirm the production configuration, access owners, backups, monitoring, support route and recovery plan. Identify the person who can authorise a rollback or pause a troubled feature. If a store release is part of the scope, include store accounts, listing materials and review time in the plan.

Handover should leave the business able to operate the product: documented accounts, an agreed source-code arrangement, data export and a clear support boundary. Review these alongside the ongoing cost of owning the app.

The first weeks of real use

Look for evidence that people can finish the intended task. Support questions, abandoned steps and failed operations can point to useful changes. Agree how you will review this evidence and prioritise the next release.

Cloudfusion's software and digital product service covers planning, design, development and the connections around the product. Start with the journey you need to improve; the milestones should follow the risks and needs of that project.