Mobile App Development: The Seven Phases of the Project

Casaverde, a home goods retailer, approved a mobile app in January and expected it in customers’ hands by summer. The build team delivered on time. The app still did not launch: the loyalty database had never been exposed through an API, nobody had booked the store review window, and the launch campaign was written around a feature cut in week nine.

Nothing on that list is a coding problem. All of it is project management, and it is the ordinary way app projects fail: the software gets built and the project does not finish.

A mobile app development project runs from an identified user need to a published, maintained product. It has seven phases, and only one of them is writing code.

An app earns a place on the phone that the web never gets

Before any phase matters, the business case has to survive one question: what does an app do that a mobile site cannot? The answer is short, and it is about proximity rather than features.

What the app buys you	What a mobile site cannot match
Mind share	Your icon sits on the home screen, seen dozens of times a day, opened or not
Immediate availability	One tap, no browser, no search, no URL to remember
A direct channel	News, images and offers reach the customer with no intermediary
A closer relationship	Two-way contact in the moment, not a form answered next week
Content that travels	Native sharing pushes your content into the customer’s own social graph
Store visibility	The App Store and Google Play put you in front of people already searching your category
Push notifications	Offers, surveys and reminders land on the lock screen. Overuse them and you get uninstalled
Real engagement	Behavior, location and timing let you answer a profile instead of an average

Every one of those is a reason to build. None of them is a plan.

An app is almost never one project

Casaverde thought it was buying an app. What it commissioned was three projects sharing one launch date: the business development work that turns the new channel into revenue, the data integration work that exposes the loyalty and catalogue systems, and the build itself. Different teams, different skills, different sponsors.

So the project manager’s job here is not scheduling developers. It is mediating between sponsor and team, holding the delivery tempo against a fixed launch, and owning what happens after it. The PMO or portfolio manager sits above all three, watching which dependencies outside the app project can delay it. A directive PMO does more than watch: it moves budget and people off secondary work to unblock the integration holding up the release.

In ITM Platform that grouping is a program. Projects and services are added as components, a project belongs to only one program at a time, and the program’s Schedule section shows the dependencies between member projects in one place. Budget rolls up the same way, a top-down program budget alongside the aggregated budgets of its components, so the cost of the app is the cost of the whole program rather than of the build alone. The setup is in program management.

The sponsor is usually the innovation lead or the CIO, because the app has to answer to the strategic plan before it answers to a design brief.

The seven phases, and what each one owes the next

These seven phases are one instance of the general project life cycle. What makes app work distinctive is that phases 3 to 6 loop, while 1, 2 and 7 happen once.

Phase	What it has to produce	You are done when
1. Idea	A named problem the app solves, not a feature list	You can say which customer job moves onto the phone
2. Planning	Market study, MVP definition, schedule, budget, business case	The business case survives its own numbers
3. Build	Research, wireframe, technical feasibility, working code	A prototype exists that a stranger can operate
4. Prototype	A rough but navigable version of the product	It is realistic enough to produce honest feedback
5. Testing	Observed sessions with people who match your real users	You have watched people fail, not just heard opinions
6. Review and improve	New user stories and a fixed definition of done	The backlog stops growing faster than it shrinks
7. Launch and maintenance	A published app plus an update and support plan	The store approves it and someone owns the bug queue

Phase 3 carries most of the risk, so it is worth opening up:

• Research. Establish what competitors already do well and what your back end must support. This is the last point at which scope is cheap to cut.
• Wireframe and documentation. Map the screens, then map the route a user takes between them. A wireframe is a navigation argument, not a drawing.
• Technical feasibility. Confirm the back end can serve the functionality, identify the public APIs you depend on, and check what each platform and form factor demands. Choosing iOS, Android or both belongs here, not in the idea phase.
• Development. Split the product into user stories and allocate them to cycles of roughly two weeks, so a testable prototype exists early instead of at the end.

Development is where a fixed launch date and an iterative build have to coexist, the same tension covered in managing agile and waterfall together. In ITM Platform, sprints are enabled per project from the General tab under Timeline, and they are not reserved for agile projects: a predictive project can sort and filter its schedule by sprint, so the launch plan and the build cadence read off one task list. Stories that are not ready move to the backlog, which deallocates them from the sprint instead of leaving them counted in it. Switching sprints on, per project or by project type, is covered in sprints.

The estimate hides in the rate, not in the feature list

The first number anyone asks for is the total, and it is the least informative one. Build cost is a product of scope and rate, and both move.

Build cost = Σ (feature effort in hours × blended hourly rate) + design + platform and compliance overhead

The blended rate is where estimates go wrong: the same feature is quoted very differently depending on who writes it.

Who builds it	Illustrative hourly rate	What you are actually buying
Junior freelancer	$30	Cheap hours and unpriced supervision
Specialist agency	$80	Delivery capacity and a contract you can enforce
Senior in-house engineer	$120	Knowledge that stays with you after launch

Same feature set, a fourfold spread on the invoice. Which is why “what does an app cost” has no answer and “how many hours, at whose rate, on how many platforms” does. Shipping on iOS and Android is close to two builds unless you commit to a cross-platform framework early, and that decision belongs in the feasibility step, not in a later change request.

Testing and launch are where the numbers usually vanish

Testing is not a demo. Put the prototype in front of people who match your real users, give them a task, and watch where they hesitate. Opinions gathered afterwards are worth far less than the three seconds someone spent hunting for a button that was not there.

What comes back becomes new user stories, and the loop through build, prototype and test runs again. What stops that loop running forever is not discipline, it is a written rule:

Definition of done: a story is finished when it is coded, reviewed, tested on every target platform and accepted by the product owner. Anything short of that returns to the backlog.

Then the launch. Store submission takes hours or days depending on how cleanly the build meets each store’s policies, so it belongs on the schedule as a task with a risk attached, not as an afterthought past the last milestone. After that comes the part plans routinely omit: updates, new features, and support for the defects testing did not catch.

This is also where an app project quietly loses its numbers. Tester feedback, store rejections and post-launch bug reports arrive as messages, get fixed, and leave no record of what they cost. In ITM Platform this is issue tracking, not a second backlog: an issue is typed as Bug, Change request or Problem, so a defect found in testing and a scope change requested after the demo are not filed as the same thing, and closing one records a change in project cost and a schedule variation in days. The dashboard totals the cost of changes from closed issues and the cost of issues by type, which turns “we had a lot of bugs” into a figure the next release can be estimated with. Issue types and resolution fields are in risk and issue management.

App projects fail in the same three places every time: a business case that never became a plan, a build that was tracked while its dependencies were not, and a launch with no owner the morning after it shipped. The seven phases are not the hard part. Keeping them attached to everything else the app depends on is.

Next steps

• Start a free ITM Platform trial and set up the app build and its integration work as components of one program.
• See how programs and portfolio management keeps dependencies between related projects visible.
• Get the delivery cadence right first: sprints work on predictive schedules as well as agile boards.