Short answer
A basic app typically takes three to six months to build, a mid-level app six to nine months, and an advanced app nine to twelve months or more, according to GoodFirms’ 2026 research with 267 app development companies. Clutch’s September 2026 data puts the average app project at about 11 months. A tightly scoped MVP can reach the stores well inside those ranges if the scope is small, decisions are quick and store requirements are handled early. Below: timelines by complexity, each phase explained, Apple and Google review times from their own documentation, the usual causes of delay, and an illustrative 12-week MVP plan.
The short answer: app timelines by complexity
How long an app takes depends mostly on how much it has to do. An app with login, profiles and some content is a different project from one with payments, real-time chat, several user roles and offline sync. GoodFirms’ 2026 cost research, based on insights from 267 mobile app development companies, gives the ranges below, and a worked example of a mid-level food delivery app at six to eight months.
Clutch, which publishes pricing guides built from verified client reviews, reports an average app project duration of about 11 months, with most projects costing US$10,000 to US$49,999 and an average of US$90,780. Averages include long-running engagements and large products, so treat them as an upper reference, not a target.
| Complexity | Typical features | Timeline (GoodFirms) |
|---|---|---|
| Basic | Login, profile, static content, simple navigation, basic push notifications | 3–6 months |
| Mid-level | Custom UI, social login, payments, real-time updates, third-party APIs, search | 6–9 months |
| Advanced | Chat, subscriptions, AI features, multi-role users, offline sync | 9–12 months |
| Enterprise | Compliance (GDPR, HIPAA), ERP or CRM integration, role-based access, heavy data | 12–18+ months |
Source: GoodFirms, How Much Does It Cost to Develop an App in 2026? (updated September 25, 2026), and Clutch Mobile App Development Pricing Guide (updated September 21, 2026). A narrowly scoped first version can ship faster than these ranges.
The phases of an app project
Every app project goes through the same phases, whether they take a week or a quarter each: discovery, design, build, quality assurance, and store review and launch. They overlap in practice, but skipping one usually costs more time later than it saved.
Discovery turns an idea into a written scope: users, the few tasks they must complete, what is out of scope for version one, and the technical choices. Design produces the screens and the flow, first as wireframes, then as a clickable prototype. Build covers the app itself, the back end and the integrations. QA tests on real devices, fixes bugs and checks performance, accessibility and security. The last phase covers store listings, privacy disclosures, review and release.
| Phase | What it produces | Illustrative range for a small MVP |
|---|---|---|
| Discovery | Written scope, user stories, priorities, technical plan | 1–2 weeks |
| Design | Wireframes, clickable prototype, visual design of key screens | 2–3 weeks |
| Build | App, back end, integrations, in weekly or bi-weekly increments | 5–8 weeks |
| QA and hardening | Device testing, bug fixes, performance and accessibility checks | 1–2 weeks, plus testing during build |
| Store review and launch | Listings, privacy disclosures, review, release | Days on Apple; up to 7 days or more on Google, plus Google’s closed-testing rule for new personal accounts |
Phase ranges are illustrative planning figures for a narrowly scoped MVP, not market statistics. Larger apps stretch the build and QA phases the most. Store review figures come from Apple and Google documentation, detailed below.
App Store and Google Play review times
Store review is usually the shortest phase, but the rules around it can add weeks if you discover them late. Plan for both stores from the first week.
Apple states that, on average, 90% of submissions are reviewed in less than 24 hours, and that you can request an expedited review for a critical bug fix or an event-related release. Beta testing with external testers through TestFlight also requires your first build to be approved by App Review for TestFlight; you can invite up to 10,000 external testers.
Google says that for certain developer accounts it takes more time to review apps, which may result in review times of up to seven days or longer in exceptional cases. More important for timelines: personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers who have been opted in continuously for at least 14 days before they can apply for production access. If nobody plans for that, a finished Android app can wait two to three weeks for its first public release.
| Store step | What the store says | Planning tip |
|---|---|---|
| Apple App Review | 90% of submissions reviewed in under 24 hours, on average | Submit early in the week; keep a buffer for a rejection and resubmission |
| Apple TestFlight (external) | First build must be approved by App Review for TestFlight | Send a beta build to App Review during the build phase, not at the end |
| Apple expedited review | Available for critical bug fixes and event-driven releases | Do not plan a launch around it |
| Google Play review | Up to 7 days or longer in exceptional cases for certain accounts | Submit at least a week before the planned launch |
| Google Play new personal accounts | Closed test with 12+ testers opted in for 14+ continuous days before production | Start the closed test by mid-build |
From Apple Developer (App Review and TestFlight pages) and Play Console Help (review times and testing requirements for new personal developer accounts), viewed September 28, 2026.
What slows app projects down
Most app delays are not caused by slow coding. They come from decisions, dependencies and scope that keep moving. The good news is that almost all of them can be anticipated at the start.
- Scope creep: “one more feature” added during the build, without removing anything else.
- Slow decisions and approvals: a design waiting two weeks for feedback delays everything behind it.
- Missing content: texts, images, pricing rules or legal pages that only the client can provide.
- Third-party dependencies: payment providers, APIs or partner systems with their own onboarding, credentials and test environments.
- Store requirements discovered late: developer accounts, privacy disclosures, Google’s closed-testing period for new personal accounts, and review rejections.
- Unclear ownership: nobody on the client side empowered to say yes or no.
- Late testing on real devices, which surfaces problems when they are most expensive to fix.
- Integrating with legacy systems whose documentation does not match reality.
How to ship an MVP faster
An MVP (minimum viable product) is the smallest version of the app that lets real users complete the core task and gives you evidence about what to build next. Speed comes from saying no, not from working longer hours.
- Pick one primary user and one core task for version one; everything else goes on a written “later” list.
- Use one cross-platform codebase (such as React Native or Flutter) or a progressive web app when native-only features are not essential.
- Use managed services for authentication, database, payments and notifications instead of building them.
- Replace features with manual work at first: an admin sends the email, approves the account or adjusts the price by hand.
- Make decisions weekly: one demo, one feedback session, one decision owner.
- Create the Apple and Google developer accounts in your company’s name in week one, and start Google’s closed test early.
- Fix the price and scope per phase so that changes are explicit trade-offs rather than silent delays.
Phased delivery: release in steps, not in one big bang
Phased delivery splits the app into releases that each go to real users: first the MVP, then the features that the MVP’s users actually ask for. It shortens the time to a first launch and reduces the risk of spending months on features nobody uses.
For the buyer, phased delivery works best with a fixed price per phase. Each phase has its own written scope, price and acceptance criteria; at the end of each one you can continue, change direction or stop, and you keep everything delivered so far. That is only true if the code, the developer accounts and the cloud accounts are in your name, which you should insist on from the first commit.
| Phase | Goal | Typical content |
|---|---|---|
| Phase 1: MVP | Prove that users complete the core task | One user type, core flow, login, basic admin, analytics |
| Phase 2: Retention | Make users come back | Notifications, profiles, history, improvements from feedback |
| Phase 3: Revenue and scale | Monetize and handle growth | Payments or subscriptions, roles, integrations, performance work |
| Ongoing | Keep it healthy | OS updates, security patches, store policy changes, small features |
A sample 12-week MVP plan
The plan below is illustrative, not a commitment for any specific project. It assumes a narrowly scoped MVP on one cross-platform codebase, a client who can give feedback weekly, content ready by week 4, and no complex legacy integrations. Real plans are adjusted after discovery.
| Weeks | Work | Client input |
|---|---|---|
| 1–2 | Discovery: scope, user stories, “later” list, technical plan; Apple and Google developer accounts created | Workshop, decisions on priorities, account access |
| 3–4 | Design: wireframes, clickable prototype, visual design; data model and authentication started | Feedback on the prototype within a few days; texts and images |
| 5–6 | Build sprint 1: core flow end to end on test devices | Weekly demo and feedback |
| 7–8 | Build sprint 2: admin, notifications, integrations; first TestFlight build sent to App Review; Google closed test started | Recruit at least 12 testers for the closed test |
| 9–10 | Build sprint 3: remaining must-haves, analytics, edge cases; testing on real devices | Test with real users; report issues |
| 11 | QA and hardening: bug fixes, performance, accessibility; store listings and privacy disclosures | Approve listings, screenshots and privacy answers |
| 12 | Store submission and launch; monitoring of the first users | Launch communication |
Illustrative plan. Apple reviews 90% of submissions in under 24 hours on average; Google can take up to seven days or longer for certain accounts, and new personal accounts need a 14-day closed test, which is why the test starts in weeks 7–8.
Web apps and PWAs: a shorter path to launch
If your users mainly work at a desk, or if the app is an internal tool, a web app or progressive web app can go live without any store review. Updates are published instantly, and one codebase serves every device with a browser.
The trade-offs are discoverability in the stores and some device features. If store presence is essential later, a web MVP can prove the concept first and a native or cross-platform app can follow in a second phase.
What ZeniTech charges
ZeniTech is a web, app, automation and AI agency based in Québec City, working remotely with clients across North America and Europe on Eastern Time, in English or French. We plan app projects phase by phase, starting with a short discovery that produces a written scope, a timeline and a fixed price for each phase.
The code repository is in the client’s name from the first commit, and so are the developer and cloud accounts. You can stop after any phase and keep everything delivered.
| Service | Price (CAD, before taxes) | Approx. USD |
|---|---|---|
| Mobile app (iOS and Android) | From $25,000 | approx. $17,650 |
| Custom software or web app | From $15,000 | approx. $10,590 |
| AI features or agent inside the app (powered by Orvel AI), setup | $3,000 to $7,500 | approx. $2,120 to $5,290 |
| Automation workflow | $750 or $2,500 | approx. $530 or $1,765 |
| Additional work | $125/hour | approx. $88/hour |
Conversions use the Bank of Canada rate of 1.4168 CAD per USD (September 28, 2026) and are rounded. Apple and Google developer fees are paid directly by you, in your name.
Frequently asked questions
How long does it take to build an app?
GoodFirms’ 2026 research with 267 app development companies puts a basic app at three to six months, a mid-level app at six to nine months, an advanced app at nine to twelve months and enterprise apps at twelve to eighteen months or more. Clutch reports an average project length of about 11 months. A tightly scoped MVP can launch well inside those ranges; our illustrative plan uses 12 weeks.
How long does an MVP take to build?
A narrowly scoped MVP, with one type of user, one core task and one cross-platform codebase, can typically be planned for around 12 weeks from discovery to store submission, as in our illustrative plan. It gets longer with payments, complex integrations, several user roles, or slow feedback. The biggest lever is scope: move everything non-essential to a written “later” list.
How long does Apple take to review an app?
Apple states that on average 90% of submissions are reviewed in less than 24 hours. You can request an expedited review for a critical bug fix or an event-related release, but do not plan a launch around it. Keep a buffer for a possible rejection and resubmission, and remember that your first external TestFlight build also needs review.
How long does Google Play take to review an app?
Google says review can take up to seven days or longer in exceptional cases for certain developer accounts. In addition, personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in for 14 continuous days before applying for production access. Start that test during the build, not after it.
Why do app projects take longer than planned?
Mostly because of scope added during the build, slow decisions and approvals, missing content, third-party dependencies such as payment providers or partner APIs, and store requirements discovered late. Late testing on real devices is another common cause. A written scope, weekly demos with one decision owner and a fixed price per phase prevent most of these delays.
Is a cross-platform app faster to build than native apps?
Usually, yes. One codebase in React Native or Flutter serves both iOS and Android, so most features are built and tested once instead of twice. Native development still makes sense for apps that depend heavily on platform-specific features or performance. A progressive web app is faster again, since it skips store review entirely, at the cost of some device features.
Can I launch in phases instead of all at once?
Yes, and it is usually the better choice. Launch an MVP that lets real users complete the core task, then add the features they ask for in later phases. With a fixed price and written scope per phase, you can continue, change direction or stop after each one, as long as the code and store accounts are in your name.
Related
Free consultation
Get a fixed price for your project in 30 minutes.
We look at what the project has to achieve, tell you what it costs, and tell you when you do not need it.
Book a call →+1 581-748-7017Sources
- GoodFirms: How Much Does It Cost to Develop an App in 2026? (updated September 25, 2026)
- Clutch: Mobile App Development Pricing Guide (updated September 21, 2026)
- Apple Developer: App Review (viewed September 2026)
- Apple Developer: TestFlight (viewed September 2026)
- Play Console Help: Prepare your app for review (viewed September 2026)
- Play Console Help: App testing requirements for new personal developer accounts (viewed September 2026)
- Bank of Canada: Daily exchange rates (September 28, 2026)