Mobile delivery planning guide

How long does it take to build a mobile app?

There is no useful generic duration. Define the smallest viable product that solves the core problem, estimate it from real dependencies and launch it to learn what should be built next.

Plan the first release Jump to estimate approach

Published 30 August 2026 · 12 minute read

The short answer

A mobile app takes as long as its viable first-release boundary and critical dependencies require. A narrow prototype, an internal operational tool and a customer-facing product with connected systems are fundamentally different projects. A generic duration hides that difference instead of helping the buyer plan.

Define the smallest product that lets a real user solve the core problem from end to end. Work with the developer or delivery team to validate the riskiest integration, identify the release and support requirements, and estimate that specific boundary. Launch to an appropriate first group, observe real use and plan later phases from evidence rather than trying to predict the entire product upfront.

Build the estimate around a viable first release

Planning question	Evidence needed	How it shapes the schedule
What must the user achieve?	One core problem and one complete outcome	Creates a finishable boundary instead of a growing feature list
What could block delivery?	Backend access, data, device SDKs, offline rules and account ownership	Reveals the dependencies that need early validation
What makes the release viable?	Acceptance, security, diagnostics, device coverage, pilot and support needs	Includes the production work that screen-based estimates often omit
What can wait?	Optional journeys and refinements that need evidence	Protects the first release while preserving a roadmap for later learning

The estimate should change when discovery changes the evidence. That is responsible planning, not a failure of planning.

Plan six evidence-producing stages

Discovery: define user, problem, outcome, platform, data, risks and acceptance.
Technical validation: prove the least certain backend, device or offline assumption.
Product design: test the complete journey, states and accessibility.
Vertical-slice delivery: connect interface, identity, backend and observability.
Pilot: use representative devices, users, data and failure cases.
Release and learn: complete store or managed distribution, monitor and decide what deserves the next investment.

Do not turn these into isolated handoffs. Design, engineering and testing should work together around a usable increment.

The critical path usually sits outside screen development

Decision

Scope clarity

Available owners, stable priorities and fast acceptance feedback.

Backend

API and data readiness

Identity, contracts, test environments, representative records and failure handling.

Device

Integration uncertainty

Vendor SDKs, permissions, hardware availability and operating-system behaviour.

Network

Offline complexity

Local state, queues, conflicts, retry, synchronisation and user feedback.

Coverage

Platforms and devices

Operating-system versions, form factors, accessibility and performance.

Organisation

Accounts and approvals

Legal identity, privacy information, store access and stakeholder decisions.

How can Cursor, Claude and Codex change delivery?

AI coding tools can compress selected parts of the development loop. A capable team can use them to map an unfamiliar repository, draft a vertical slice, generate repetitive code and test cases, explain failures, compare approaches, update documentation and prepare changes for review. Independent, well-defined tasks can also progress in parallel.

That does not mean the whole project becomes faster by the same amount. Research results differ between bounded programming tasks and experienced developers working in mature repositories. Time saved in initial code generation can move into prompting, review, correction and integration when the context or feedback system is weak.

DORA describes AI as an amplifier. Strong specifications, modular architecture, automated tests, small change sets and fast human review make AI-generated work easier to validate. Cursor, Claude and Codex should therefore be included in the delivery method, but not used as a substitute for estimating the actual viable product.

Workstream	Where AI can help	What still controls elapsed time
Discovery and design	Synthesise inputs, explore alternatives and draft specifications	User evidence, stakeholder decisions and approved product boundaries
Implementation	Scaffolding, routine code, refactoring, documentation and first-pass debugging	Architecture, repository context, integration quality and human review
Verification	Generate test cases and inspect likely failure paths	Representative data, real devices, security judgement and acceptance
Release	Prepare checklists, release notes and repeatable automation	Accounts, policy compliance, store review, pilot evidence and operational readiness

Store submission is a workstream, not the last task

Apple requires complete builds, accurate metadata and review information, including access instructions where login is required. Google Play separates testing, review and production states, and review conditions can vary. Prepare accounts, signing, listings, privacy details, demo users and release ownership during delivery.

use controlled testing or managed distribution for pilots;
submit a complete, stable release candidate;
allow contingency for questions, corrections and storefront propagation; and
do not make a public event depend on an unreviewed first submission.

Accelerate decisions and uncertainty, not verification away

give one product owner authority over the first-release boundary;
reuse an existing identity and backend where it meets the need;
prototype the critical SDK or offline path during discovery;
use AI on bounded tasks with explicit acceptance tests and reviewable diffs;
prepare representative data and test accounts early;
run design, implementation and device testing in small vertical slices;
measure whether AI-assisted work reduces cycle time rather than relying on perceived speed;
limit device coverage deliberately and document it; and
release to a controlled pilot before broad rollout.

Build a timeline from dependencies

Record the outcome, essential first-release journeys, deferred ideas, platforms, backend owners, required device capability, test devices, data, security review, account access, decision-makers, acceptance examples, pilot group and release method. Put uncertainty on the plan rather than hiding it inside a generic date.

If AI-assisted delivery is part of the approach, also record the allowed tools, data-handling rules, repository context, review owner, test gates and the metric used to confirm whether the workflow is improving delivery.

Pair the plan with the South African mobile cost guide, the mobile vs web decision and the mobile app development service.

Sources and basis

AI-development and release references