App development moves through discovery, scope, design, technical planning, development, testing, launch, and iteration. The useful question at each stage is not whether a document is finished. It is whether the team has enough evidence to make the next decision without hiding a costly risk.
These stages can overlap. A team can prototype while it tests demand, for example. But it should not approve a full build before it can name the first user, the core workflow, and the assumption that release will test.
The main app development stages
| Stage | Output to review before moving on |
|---|---|
| Discovery | Named first user, problem, current alternative, and learning goal |
| Scope | One core workflow, version-one inclusions, and explicit exclusions |
| Product design | Prototype that covers success, empty, error, and permission states |
| Technical planning | Platform choice, data and integration dependencies, and the highest-risk technical test |
| Development | Working slices of the core workflow with reviewable acceptance criteria |
| QA | Evidence that high-risk paths work, plus known issues and a release decision |
| Launch prep | Instrumentation, support owner, rollback path, and store or deployment requirements |
| Release | A limited or general release with a clear owner and feedback channel |
| Iteration | A keep, change, or stop decision based on the learning goal |
These are decision checks, not a requirement to produce nine separate documents. For a small MVP, several outputs can fit on one page. For a regulated or integration-heavy app, each may need more evidence.
Discovery and scope
Discovery defines why the app should exist. Scope defines what the first version should include.
Ask:
- Who is the first user?
- What problem does the app solve?
- What is the core workflow?
- What should users be able to do on day one?
- What can be manual behind the scenes?
- What should wait until after validation?
Before scope is approved, write down what evidence would cause you to change it. If nobody can name the decision that the first release will inform, reduce the scope or test the assumption without building an app.
Product design
Product design turns the scope into a usable experience. It should cover user flows, screen structure, empty states, errors, permissions, and the moments where users need confidence.
For apps, design also needs to account for mobile behavior: thumb reach, navigation, loading states, form friction, offline or weak-network scenarios, and notification logic.
The design stage should not happen in isolation. Engineers need to review flows early so technical constraints do not appear after the interface is approved.
Technical planning
Technical planning decides how the app will be built.
This includes:
- Platform choice: web, iOS, Android, or cross-platform
- Architecture and backend
- Database and data model
- APIs and integrations
- Authentication and permissions
- Deployment and hosting
- Monitoring
- Security considerations
Choose the platform around the first workflow, not a default preference. If users need device features or an app-store distribution path, test those requirements early. If the same task works in a browser, a web first version may reduce the number of platforms the team must maintain. Record the assumption and revisit it after the pilot.
Prove the riskiest dependency before committing to the rest of the architecture. A payment, identity, or third-party data integration can change the workflow more than a framework choice does.
Development and QA
Development should happen in small, reviewable slices. QA should begin before the end. For mobile products, that usually means combining structured QA with manual mobile application testing on real flows and devices.
Test:
- Core workflows
- Forms and validation
- Permissions
- Payments or subscriptions if present
- Notifications
- Mobile layout
- Browser or device differences
- Integrations
- Admin actions
QA should focus first on the flows that affect trust, money, data, or the main user promise. Automation can help too, but the benefits of automation testing are strongest when the checks protect repeatable, high-risk workflows.
The release gate is a decision, not a claim that every bug is gone. List the unresolved issues, the users they affect, the owner, and the rollback or support response. Do not release a path that cannot safely complete the app’s main promise.
Launch and iteration
Launch is not the finish line. It is the first real test of the product.
Before launch, prepare:
- Analytics
- Error monitoring
- Support process
- Known limitations
- Rollback path
- Feedback collection
- Next-release decision process
For a native mobile app, allow for distribution and review outside your own deployment pipeline. Apple’s TestFlight guidance describes beta distribution and feedback before App Store review. Google Play’s release guidance distinguishes testing tracks from production. Check the rules for your account and target market before setting a launch date; they can change.
After launch, watch what users actually do. Improve the product based on evidence, not only the original roadmap.
A worked stage plan for a first app
Suppose a small service business wants an app for customers to book a visit. This is a hypothetical planning example, not a Hapy client result.
- Discover: Speak with the first customer group and observe how bookings happen now. Decide whether the app must reduce missed appointments or simply replace phone calls.
- Scope and design: Prototype booking, confirmation, cancellation, and the staff view. Defer loyalty points and referrals. Test whether customers and staff can complete the flow without help.
- Plan and build: Check calendar availability and notification delivery before polishing every screen. Build one bookable service and one staff schedule first.
- Test and release: Test double bookings, time-zone errors, failed notifications, and cancellations. Release to a limited group with a manual support path.
- Decide: Compare completed bookings, missed appointments, and support requests with the prior process. If the workflow fails, fix that before adding services or automating more work.
The same stages apply to a larger product, but the evidence and release controls change with the risk. A banking workflow, for example, needs a much stronger security and compliance review than this booking example.
The Hapy view
App development stages are useful when they protect learning. They become waste when teams follow them without making better decisions.
For MVP Development, the stages should stay lean: clarify the problem, build the smallest useful version, launch with enough quality, and learn what deserves more investment.
Use the stage outputs above to review a proposed build plan. If an output is missing, ask what decision it protects before funding the next stage.
