Plan your mobile or web app build with a Gantt chart. Covers discovery, design sprints, backend, frontend, QA, beta testing, and App Store submission timelines.
A 4-to-6 month app build involves at minimum four teams — product, design, backend engineering, and frontend/mobile engineering — working on overlapping tracks with complex handoffs. Without a visual timeline that shows what depends on what and who is blocked by whom, the default outcome is: discovery takes twice as long, design gets handed off before it's ready, engineers sit idle waiting for approved specs, and QA happens in a panicked crunch the week before launch.
A Gantt chart for app development solves the sequencing problem. It shows every phase, every handoff, every parallel workstream, and the specific dates when one team's work must land so the next team can start. This guide walks through the complete timeline for a 4-to-6 month app build — from discovery through post-launch monitoring — with specific durations, common schedule killers, and how to use a Gantt chart to stay on track.
App development projects have characteristics that make visual timeline management mandatory, not optional.
Multiple parallel workstreams with hard handoffs. Backend development and UI design happen simultaneously in weeks 4–10. But frontend development can't begin until both the API contracts are defined and the design system is approved. That handoff has a hard dependency. Miss it, and your frontend engineers spend two weeks either idle or building against a moving target.
External gates you can't control. App Store review (Apple App Store) takes 1–3 days for standard apps but can take 7–14 days for apps triggering additional review. Google Play review runs 1–7 days. You cannot force these gates. They must appear as buffer in your Gantt chart, or your "launch date" will slip on the day you submit.
QA at the end is the #1 schedule killer. Most app projects treat QA as a final phase that happens after development is complete. What actually happens: development finishes 2 weeks late, QA has 1 week instead of 3, and either you launch with known bugs or you push the launch date. Rolling QA — where QA begins testing completed features in parallel with ongoing development — eliminates this problem. Your Gantt chart makes rolling QA visible and schedulable.
Design/dev handoff is a process, not a moment. Handing Figma files to engineers is not a handoff. A real handoff includes component specs, interaction states (hover, loading, error, empty states), responsive breakpoints, and asset exports. Build 3–5 days of handoff preparation into your Gantt chart after each major design phase. This is not wasted time — it is the difference between a clean build and a build with 200 design revision tickets.
The following timeline is based on a 4-to-6 month build for a native mobile app (iOS + Android) or a web app with similar functional complexity. Adjust durations based on team size and feature scope.
This phase is underestimated on almost every project. Two weeks of discovery for a complex app is not enough. Three weeks is realistic.
Tasks:
Typical duration: 2–3 weeks.
The non-negotiable output from discovery: a signed PRD and a feature list with explicit scope boundaries. Without this, scope creep starts in week 4.
Design is not one phase — it is a sequence of deliverables, each with its own review and approval cycle. Structure it as:
| Design Milestone | Duration | Predecessor |
|---|---|---|
| Information architecture + user flow diagrams | 5 days | PRD sign-off |
| Wireframes (low-fidelity, all key screens) | 7 days | IA approved |
| Wireframe review + stakeholder feedback | 3 days | Wireframes delivered |
| UI design (high-fidelity, key screens) | 10 days | Wireframes approved |
| Design system documentation | 5 days | UI design 50% complete |
| UI design (remaining screens + edge cases) | 7 days | Key screens approved |
| Interactive prototype (Figma or Principle) | 3 days | Full UI design approved |
| Prototype user testing + revision | 5 days | Prototype delivered |
| Final design handoff package | 3 days | User testing revisions done |
Total design duration: 6–8 weeks for a medium-complexity app (15–30 unique screens).
The most common mistake: stakeholders approve wireframes and then want major structural changes after high-fidelity design is complete. Enforce a wireframe sign-off that explicitly states design iteration in high-fidelity is limited to visual refinement, not structural changes.
Backend development typically begins in week 4, overlapping with design. The key early deliverable is the API contract — the defined endpoints, request/response schemas, and authentication model that the frontend will build against.
Milestones:
For apps with a separate backend team, track their progress against the API contract as a gate. If the API contract slips from week 6 to week 9, your frontend development start date moves with it — or your frontend engineers build against mocked data and face reconciliation rework later.
Frontend development begins 2–3 weeks after the API contract is defined and the design system is ready. Running it earlier creates rework; running it later compresses the QA window.
For a React Native or Flutter mobile app:
For web apps, the timeline is similar but substitute browser compatibility testing and responsive layout verification in weeks 14–15.
The critical handoff point: week 7, when backend has the API contract and design has the design system. Both must land by week 6 for frontend development to start cleanly.
QA on a well-managed app project begins in week 9, not week 16. This is rolling QA: the QA engineer tests each completed feature as it ships from the backend and frontend teams, rather than waiting for a complete build.
How rolling QA works on the Gantt chart:
The distinction between critical and high-severity bugs matters for scheduling. Critical bugs (crashes, data loss, security vulnerabilities) block release. High-severity bugs (broken core features) block release. Medium and low severity (cosmetic issues, minor UX inconsistencies) can ship if explicitly accepted. Define this severity matrix in your QA plan and reference it on the Gantt chart — it's the basis for the release decision meeting in week 18.
A closed beta with 20–100 real users surfaces the bugs and UX failures your team's own testing misses. This phase runs in parallel with QA's final regression.
Beta distribution:
Run the beta for 2 weeks minimum. One week is too short to get useful feedback patterns — many users won't open the app until day 5 or 6.
Track beta feedback in a dedicated triage board. On the Gantt chart, add a "Beta feedback triage" task running from week 17 through week 18. This is where you make the hardest project management decision: which beta feedback gets fixed before launch, and which goes into the v1.1 backlog.
App Store submission is not a one-day task. Allow 2 full weeks.
Tasks:
Mark your public launch date 5 business days after your submission date, not on the day you submit. Teams that submit and announce the same day get burned by review delays.
Post-launch is not the end of the project. It is a separate workstream that needs its own Gantt chart section.
The first 4 weeks after launch typically require:
Block at least 30% of your engineering team's capacity for the 4 weeks after launch. Teams that fully commit to new feature development immediately after launch routinely discover critical bugs they can't respond to quickly.
The handoff from design to development is the most consistently underestimated phase in app project timelines. A real handoff includes:
On your Gantt chart, treat handoff as a 3–5 day task after each major design milestone, not a zero-duration event. This is preparation time for the designer — not development time. Engineers should not start building until the handoff package is complete.
The rolling QA approach requires coordination between your engineering and QA leads. Here's how to structure it:
Feature flag everything. Each completed feature ships behind a feature flag. QA tests the flagged feature in staging. This means QA can test authentication while backend engineers are still building the core data features.
Define "QA-ready" criteria. A feature is QA-ready when: it has unit tests passing, it works against the real backend (not mocks), and all required screens have been implemented (including error states). Without this definition, features get handed to QA prematurely and QA tickets pile up that should have been caught during development.
Two-day QA notification rule. Engineering notifies QA 2 days before a feature is QA-ready. This prevents QA from being ambushed and gives them time to write test cases.
Bug severity triage meeting — weekly. Once a week (30 minutes), the product manager, QA lead, and engineering lead review open bugs, assign severity, and set fix-by dates. This is the meeting that determines whether you're on track for your release date.
Based on a team of 1 product manager, 1 designer, 2 backend engineers, 2 frontend/mobile engineers, and 1 QA engineer:
| Phase | Duration |
|---|---|
| Discovery and requirements | 2–3 weeks |
| Design sprints | 6–8 weeks |
| Backend development | 10–12 weeks (starts week 4) |
| Frontend/mobile development | 9–10 weeks (starts week 7) |
| Rolling QA | 10 weeks (starts week 9) |
| Closed beta | 2 weeks |
| App Store submission + launch | 2 weeks |
| Post-launch monitoring | 4 weeks (ongoing) |
Total calendar time: 20–24 weeks (5–6 months).
Add 2–4 weeks if any of the following apply: first-time work with this tech stack, complex third-party integrations (payment processors, identity providers, healthcare data systems), or a distributed team across 3+ time zones.
Q: Should I use a Gantt chart or Jira for app development planning?
Use both. Jira (or Linear, GitHub Issues, etc.) tracks individual tickets at the sprint level — the tactical, day-to-day work. A Gantt chart tracks phases, milestones, and dependencies at the release-planning level — the strategic, multi-week view. Your engineering team should never need to open the Gantt chart for daily standup. Your product manager and stakeholders should never need to open Jira for release planning.
Q: How do I account for scope changes mid-project?
Every scope change request should trigger a Gantt chart impact analysis before it's accepted. Adding a feature mid-project is not free. A feature that takes 5 development days also costs 2 days of design revision, 3 days of QA time, and pushes the launch date by at least 1 week when buffer is consumed. Show the impact on the Gantt chart before accepting the scope change, not after.
Q: What if the backend and frontend teams have different sprint lengths?
This is common. Treat each team's sprint cadence independently in the Gantt chart, but mark the cross-team handoff points as explicit milestones. "API contract final" is a milestone that frontend depends on, regardless of which sprint it falls in for the backend team. Focus on outcomes (API contract delivered), not on synchronizing sprint boundaries.
Q: How do I handle App Store rejection in my timeline?
Build 5 business days of buffer between your App Store submission date and your announced launch date. For apps in categories that trigger additional review (apps for kids, healthcare apps, apps with subscriptions, apps with user-generated content), budget 10–14 days. If you're rejected, the Gantt chart tells you immediately how much your launch date slips and which downstream tasks (press release, social posts, email announcement) need to move.
Q: When should I involve QA in the project?
Week 1, during discovery. A QA engineer who reads the PRD and user stories during discovery writes better test cases and catches ambiguous requirements before they become expensive bugs. QA involvement at the very end of a project is a legacy pattern from waterfall development. Start earlier and you'll ship with fewer surprises.
Go to gantt-chart.io, set your target launch date, and work backward through the phases above. Build the timeline before you start — not halfway through when you realize QA has 1 week instead of 3.
For mapping out complex user flows and system architecture alongside your timeline, flow-chart.io handles the logic diagrams. When you need to present the build plan to investors or stakeholders, slide-deck.io turns the Gantt chart into a polished presentation in minutes.