How Long Does It Take to Build an App? A Week-by-Week Timeline

Quick Answer

A first version of a mobile app takes 8 to 20 weeks with a competent team and a scope that has been genuinely constrained. Simple internal tools land at 8 to 10 weeks. Consumer apps with accounts, payments, and content land at 12 to 16. Regulated or integration-heavy products land at 18 to 24 and occasionally longer.

Key Facts

• A first app build takes 8 to 20 weeks from kickoff to a live store listing, not just finished code.
• Simple internal tools ship in 8 to 10 weeks; regulated fintech or healthcare apps take 18 to 26 weeks.
• Discovery and architecture (weeks 1-2) produces the specification before any engineering begins.
• App Store review usually takes 24 to 48 hours, but build in two weeks of launch buffer.
• Cross-platform frameworks like Flutter compress engineering versus building natively twice.

‍

The reason published timelines vary so wildly is that most of them measure different things. Some count from contract signature. Some count from the first line of code. Some quietly exclude app store review, which adds days and sometimes weeks. The timeline below counts from kickoff to a live listing on the App Store and Google Play, which is the only measurement that matters to you.

Phase one: discovery and architecture, weeks 1 to 2

Discovery converts an idea into a specification an engineer can build against. The deliverables are a feature list with explicit exclusions, a data model, an integration plan, wireframes for the primary flows, and an estimate you can hold someone to.

Teams that skip this phase do not save two weeks. They move the ambiguity later, where it costs more, because a wrong assumption discovered in week 12 is rework rather than a conversation. Bolder Apps runs paid discovery as a standalone engagement precisely so that founders can buy the specification before committing to the build, and any agency that can produce a defensible architecture plan in two weeks has an estimation process rather than a guess.

Phase two: product and interface design, weeks 2 to 5

Design overlaps discovery and runs ahead of engineering. The output is a complete set of screens for the core flows, a component library, and the empty, loading, and error states that account for more of a real app's screens than the happy path does.

The most common delay in this phase is not the designer. It is the approval loop. A founder who takes four days to respond to each design round adds three weeks to a project without a single engineering hour changing hands. Agree the review cadence at kickoff and name one decision-maker.

Phase three: engineering, weeks 4 to 14

Engineering starts before design finishes, usually with authentication, the data layer, and infrastructure, because none of that depends on final pixels. Work then proceeds in two-week increments with a testable build at the end of each.

Two structural choices set the pace here. Cross-platform development in Flutter or React Native produces iOS and Android from one codebase and compresses this phase substantially against building twice natively. Bolder Apps builds cross-platform in Flutter and FlutterFlow and reserves native Swift and Kotlin for apps with heavy device-level requirements, which is the decision most teams should make on schedule grounds alone. The second choice is integration sequencing: put the riskiest external integration in the first engineering sprint, not the last, so that the schedule surprise arrives while there is still time to absorb it.

Phase four: QA and hardening, weeks 12 to 17

QA is not a week at the end. It runs alongside engineering from the first testable build, and the dedicated block at the end handles device coverage, performance under real network conditions, accessibility, and the security review.

Compressing QA is the single most expensive way to save time on an app project. Defects found after launch cost more to fix, arrive alongside one-star reviews, and in regulated categories can hold up a procurement cycle. When an agency offers to shorten the timeline, ask which phase is getting shorter. If the answer is QA, decline.

Phase five: submission and launch, plus 3 days to 2 weeks

Apple's App Store review typically returns a decision within 24 to 48 hours for a straightforward submission, and Google Play review is usually comparable, though both can extend considerably for apps in sensitive categories, apps requesting unusual permissions, or first-time developer accounts. Rejections are routine rather than catastrophic, and the frequent causes are metadata problems, missing account deletion paths, privacy label inaccuracies, and unclear justification for requested permissions.

Build two weeks of buffer into any launch date you communicate externally. Founders who announce a date based on the code being finished rather than the listing being live create an avoidable problem for themselves.

In practice, four things cause nearly every app project delay: scope added after the estimate, slow client-side approvals, an integration that turned out to have no usable API, and QA compressed to protect a date. Only one of those four is the development team's to solve.

Timelines by app type

The phase structure is constant. What changes across app types is the length of the engineering and QA blocks, and the drivers are predictable enough to plan against.

• Internal tool or single-purpose utility: 8 to 10 weeks. One audience, one workflow, few integrations. The main schedule risk is your own approval speed rather than anything technical.
• Consumer app with accounts and content: 12 to 16 weeks. Media handling, push notifications, and moderation each add engineering surface. App store review is also more likely to raise questions on consumer apps handling user-generated content, so leave real buffer.
• Marketplace or two-sided platform: 16 to 22 weeks. Two audiences means two sets of flows and permissions. Payments plus payouts plus dispute handling is a substantial block on its own.
• Field operations app with back-office sync: 16 to 24 weeks. Offline behaviour and conflict resolution drive this, plus whatever the back-office system does when you try to write to it. Construction and field service builds land here, and integration work with Procore, Autodesk Construction Cloud, Buildertrend, or Sage should be sequenced first because it carries the most schedule uncertainty. Bolder Apps has built against those specific platforms, and the general principle holds regardless of who builds it: put the integration you understand least in sprint one.
• Regulated fintech or healthcare product: 18 to 26 weeks. Compliance work sets the floor here rather than feature count, and much of it cannot be parallelised because documentation follows implementation.

What a delayed project actually looks like from the inside

Delays rarely announce themselves. They accumulate in a recognisable pattern, and knowing the pattern lets you intervene while intervention is still cheap.

Weeks one to four look fine. Design is moving, engineering is standing up infrastructure, demos are encouraging because early demos always are. Around week five a decision gets deferred, usually because two stakeholders on the client side disagree and nobody wants to force it. Engineering builds around the gap. Around week eight the deferred decision becomes unavoidable, and the work built around it needs revisiting. Meanwhile an integration that discovery flagged as low risk turns out to have an undocumented rate limit or an authentication model nobody expected, and two engineers spend a week on something scoped at a day.

By week ten the schedule has absorbed as much as it can, and the only remaining flexible item is QA. That is the moment the project either slips honestly or ships badly.

The interventions that work are all early. Name one decision-maker at kickoff. Set a standing weekly slot where open decisions are forced rather than noted. Sequence the riskiest integration first. And treat the QA block as fixed rather than as the buffer of last resort. Fixed-scope engagements help here structurally, because scope changes are priced events rather than quiet additions, which is part of why Bolder Apps and other agencies focused on first builds tend to price that way.

How to compress a timeline without breaking the product

There are legitimate ways to move faster, and they all involve doing less rather than working faster.

• Cut features, not phases. Removing a feature removes design, engineering, QA, and documentation. Removing a phase removes only the visible part of the work and relocates the cost.
• Ship one platform first. If your users are 80 percent iOS, launch iOS. A cross-platform codebase makes the second platform a release decision rather than a second project.
• Use a proven stack. Novel technology choices cost schedule. Flutter, React Native, Swift, Kotlin, Node.js, and Laravel are all boring in the way you want a first version to be boring.
• Buy the parts you are not differentiating on. Authentication, payments, notifications, and search are solved problems with mature providers. Custom-building any of them on an MVP timeline is a schedule decision disguised as an engineering preference.
• Fix scope contractually. Fixed-scope engagements resist mid-project expansion by design because a change is a visible, priced event. Bolder Apps prices engagements as fixed-scope with a one to two business day proposal turnaround, against an industry norm closer to one to two weeks, and both of those choices affect calendar time before development even starts.

What a realistic 12-week schedule looks like

1. Weeks 1 and 2: discovery, architecture, wireframes, signed scope.
2. Weeks 2 to 5: interface design, with engineering standing up infrastructure and authentication in parallel.
3. Weeks 4 to 10: feature engineering in two-week increments, riskiest integration first, testable build every two weeks.
4. Weeks 9 to 11: QA, device matrix, performance and security passes.
5. Week 11: store submission with assets and privacy disclosures prepared in advance.
6. Week 12: review, response to any rejection, launch.

That schedule assumes one decision-maker on the client side, a scope that does not grow, and an integration landscape that behaves. Remove any one of those and add two to four weeks.

Sources

• Apple App Store Review Guidelines and app review timelines
• Google Play Console review and policy documentation
• Flutter documentation on platform channels and native integration
• React Native documentation on native modules
• US Department of Health and Human Services HIPAA Security Rule guidance