"How long will it take?" is the most common question in a first meeting about a mobile app project. The honest answer is almost always longer than the client is expecting.
A typical business app — order management, customer loyalty, field service, internal operations — takes four to six months from initial kickoff to live in both app stores. Some take longer. Very few take less. Understanding why helps you plan the project properly and avoid the expensive consequences of compressed timelines.
Phase 1: Discovery and Requirements (2-3 Weeks)
Before anyone designs or codes anything, the project team needs to understand what the app actually needs to do. A key early decision is which platform to build for — choosing between iOS, Android, and cross-platform development affects both the timeline and the budget, so it's worth settling before discovery begins. This phase means:
- Mapping the user flows: what does each type of user do in the app, step by step?
- Identifying integrations: does the app connect to an existing system — inventory, ERP, accounting, a website's backend?
- Defining user roles and permissions: who can see what, who can do what?
- Establishing scope boundaries: what's in this version, what's deferred to a later release?
This phase is often undervalued by clients who want to start seeing designs immediately. Skipping it or rushing it produces a discovery phase that happens later — during development — which is far more expensive. A feature that takes 2 hours to add in requirements takes 2 weeks to add after development has started.
A signed-off requirements document at the end of this phase is the foundation everything else is built on.
Phase 2: UX Wireframes and Design (3-4 Weeks)
Wireframes come before visual design. They show the structure of each screen — where elements are placed, what information is shown, how screens connect — without color, typography, or visual style. They're cheap to revise. Feedback at this stage costs hours; the same feedback during development costs days.
Once wireframes are approved, visual design applies the brand: colors, typography, icons, illustrations, spacing. The output is a set of high-fidelity mockups that look like the finished app but are not functional.
Client feedback rounds during design take time. Build in at least two rounds of revisions. If feedback arrives slowly — waiting a week for comments on a design — the timeline extends. This is a significant source of delays that comes from the client side, not the developer side.
Phase 3: Development (8-16 Weeks)
The range is wide because scope varies significantly. A simple app with read-only data display and basic user authentication sits at the lower end. An app with complex business logic, real-time data sync, offline functionality, multiple user roles, and several external integrations sits at the upper end.
Development has interdependencies: you can't build the order detail screen before the order list screen works, and you can't build either until the backend API is returning data in the right format. This creates a sequencing constraint that means some work can't be parallelized.
This phase is also where scope creep does the most damage. "Can we add a feature where..." mid-development doesn't just add that feature's time — it potentially requires refactoring existing work to accommodate it. Every scope change mid-development should be evaluated for timeline impact, not just individually but in terms of what it disrupts.
Phase 4: Testing (2-3 Weeks)
Testing takes longer than people expect, for a simple reason: it needs to happen on real devices.
An app that runs perfectly in a simulator may have layout issues on a Samsung Galaxy A series device with a specific screen size. It may crash on older Android versions that a meaningful percentage of Indonesian users are still running. It may behave differently on iOS 17 vs. iOS 18. Emulators don't catch all of these.
Proper testing covers:
- Functional testing (does every feature work as specified?)
- Device testing across a representative range of Android and iOS devices
- Performance testing (does the app perform acceptably on a mid-range device with variable network conditions?)
- Edge case testing (what happens when the connection drops mid-transaction? When the user has unusual data in their profile?)
Bugs found in testing are fixed and then retested. Severe bugs can send the project back to development for significant work. Budget this phase honestly — cutting it produces a buggy launch, which is worse than a delayed launch.
Phase 5: App Store Submission (1-2 Weeks)
Google Play Store review typically takes 1-3 days for a new app. This is predictable.
Apple App Store review is a different situation. Initial reviews can take 1-7 days. Apps are sometimes rejected for reasons that require code changes or additional documentation — and after those changes are made, the review clock restarts. Apple's reviewer can flag policy questions that require back-and-forth communication, and the process is not transparent from the outside.
Common Apple rejection reasons include: apps that reference payment methods outside Apple's system, apps with web content that doesn't comply with App Store guidelines, privacy policy issues, and screenshots that don't match the actual app functionality. These are avoidable with preparation, but they require knowing the rules before you submit, not after.
Build at least two weeks into the timeline for app store processes, and treat it as a minimum estimate for Apple.
The Total Picture
| Phase | Duration |
|---|---|
| Discovery and requirements | 2-3 weeks |
| UX design and visual design | 3-4 weeks |
| Development | 8-16 weeks |
| Testing | 2-3 weeks |
| App store submission | 1-2 weeks |
| Total | 16-28 weeks |
Four to seven months for a typical business app. For a complex app, longer. For a very simple app with narrow scope, potentially three months on the short end.
What Compresses Timelines (and What Doesn't)
More developers doesn't always mean faster delivery. Software development has coordination costs — adding people to a late project often makes it later. The right answer is usually fewer people working with clear scope, not more people scrambling.
What actually helps: fast client feedback during design, stable scope after requirements sign-off, content and assets delivered on schedule, and test devices available early.
What delays projects every time: scope changes mid-development, slow feedback during design review, waiting on integration partners who are not responsive, and content that isn't ready when development finishes.
If you're planning a mobile app project and want to build a realistic timeline before committing to a launch date, CERIS can help you scope it properly from the start. See our mobile app development service or get in touch for an honest estimate.
