How Long Does It Take to Build an App? Real Timelines for 2026

A founder asked us this in a discovery call last month, about ninety seconds in: "Just give me a number. How long?" He'd already been quoted six weeks by one agency and eight months by another, for what he described as the same app. He assumed one of them was lying.

Neither was. They were quoting two completely different products, because he had described his idea in a paragraph and each team had filled in the blanks differently. That gap - between what a founder pictures and what actually has to be built - is where almost every app timeline goes wrong.

This guide gives you the real numbers. How long each type of app takes, what each phase actually consumes, which factors genuinely move the schedule, and the time sinks that never appear in a proposal. We build apps for a living at CueBytes, so these are the timelines we work to, not the ones that look good in a pitch deck.

The Short Answer

Most apps take 3 to 9 months to build. A focused MVP ships in 6 to 12 weeks. A mid-size consumer or business app takes 4 to 7 months. An enterprise app takes 9 to 18 months.

If you want the version that fits on a sticky note: however long you think it will take, the honest number is usually 1.5x that - and the difference is almost never engineering. It is scope that was never nailed down, decisions that took three weeks to make, and an integration that turned out to work nothing like its documentation promised.

App Development Timeline by Project Type

These are end-to-end timelines - discovery through to a live app in the stores, not just development hours.

Notice the pattern: the jump from MVP to standard app is bigger than the jump from standard to marketplace. That is because the first version of anything carries all the foundational work - architecture, authentication, CI/CD, design system, store accounts. Once that exists, additional features get cheaper in time. The first 20% of an app takes far longer than the next 20%.

For what those timelines translate to in budget, our MVP development cost guide and startup app cost breakdown use the same project categories.

The Six Phases, and How Long Each One Really Takes

Every app project moves through the same six phases. Most quotes only price the third one, which is why most quotes are wrong.

1. Discovery and scoping - 1 to 2 weeks

Turning an idea into a specification: user flows, feature list, data model, integration list, and the explicit list of what is not in version one. Teams that skip this to "save time" reliably lose three to four times the saved time later, because every undefined decision resurfaces mid-build when it is far more expensive to answer.

This is the highest-leverage phase in the entire project. A week spent here routinely saves a month at the other end.

2. UX and UI design - 2 to 4 weeks

Wireframes, then visual design, then a component system the developers can build against. Two weeks if you are adapting an established design system; four or more if the product needs genuinely original UI and a brand identity built alongside it.

The variable here is rarely the designer's speed. It is review rounds. Three stakeholders with three opinions and no decision-maker can add two weeks to this phase without a single extra screen being drawn.

3. Development - 4 to 20+ weeks

The phase everyone thinks of as "building the app." For a lean MVP, 4 to 6 weeks. For a standard consumer app, 10 to 16. For enterprise, 20 and up.

Good teams run this in two-week sprints with something demoable at the end of each one. If a vendor cannot show you working software every two weeks, you have no way to tell whether the schedule is real until it is far too late to react.

4. QA and testing - runs throughout, plus 1 to 3 weeks

Testing should happen continuously during development, not as a phase bolted on at the end. But there is always a dedicated hardening period before launch: device matrix testing, edge cases, performance profiling, and the bug list that comes out of real users touching it for the first time.

Budget roughly 20% of development time for this. Teams that budget zero for it do not skip the work - they just discover it after launch, when fixing it costs more and users are watching.

5. App store submission - 3 days to 3 weeks

Apple's review is typically 24 to 48 hours in 2026, and Google Play is usually faster. That is the number people quote. The number that matters is how long it takes to get approved, and first submissions get rejected far more often than teams expect.

The rejections we see most often, none of which are code problems:

• Missing or non-functional account deletion. Both stores require it and both check it.
• Privacy policy gaps - the declared data collection not matching what the app actually does.
• No demo credentials for a reviewer who hits a login wall.
• Metadata and screenshots promising features the build does not have.
• Payment routing - selling digital goods outside the store's billing.

Each rejection costs a full review cycle. Two rejections turns a 48-hour phase into two weeks.

6. Post-launch stabilisation - 2 to 4 weeks

Real users find things no test plan does. The first month after launch is crash fixes, performance issues on devices you never tested, and the onboarding drop-off you did not predict. This is part of the project, not an afterthought - and a vendor whose timeline ends at "submitted to the App Store" has quoted you an incomplete project.

What Actually Drives the Timeline

Founders assume feature count is the driver. It is a factor, but four other things move the schedule harder.

Integrations, not features

Ten screens reading from your own database is a fast build. Three screens talking to a legacy ERP, an insurance provider's API, and a bank's sandbox is slow, and the slowness is unpredictable, because you are dependent on someone else's documentation being accurate and their sandbox being up. Every third-party integration adds 3 to 10 days, and the badly documented ones add more.

Backend complexity

A managed backend like Firebase or Supabase can remove weeks of work. A custom backend with its own business logic, background jobs, and data pipeline adds them back. This is usually the biggest single fork in the timeline, and it is a decision worth making deliberately rather than by default.

Number of user roles

This one is consistently underestimated. Each distinct user type - customer, provider, admin, support - is effectively its own app surface with its own screens, permissions, and test cases. Going from one role to three does not add 30% to the timeline. It roughly doubles it.

Design originality

Standard patterns with a good component library are fast. Custom animations, bespoke interactions, and a distinctive brand experience are slow - not because they are hard to build, but because they need iteration to feel right. Worth it for a consumer product competing on experience; a poor trade for an internal tool.

Regulation

HIPAA, SOC 2, PCI-DSS, GDPR at scale. Compliance work is mostly not code - it is documentation, audits, access controls, and review cycles that run on external schedules you do not control. Regulated apps take 30 to 50% longer, and the extra time lands in phases most plans do not account for. Our enterprise app cost breakdown covers where that effort goes.

Want a timeline built on your actual scope rather than a category average? Book a free scoping call with CueBytes →

The Time Sinks Nobody Puts in the Proposal

These are the things that turn a well-estimated project into a late one. None of them are engineering problems.

• Client feedback latency. The most underrated variable in the whole project. A team that responds in a day ships materially faster than one that responds in a week - same scope, same developers. Over a four-month project, slow feedback loops alone can add a month.
• Scope that was never actually agreed. "Users can share their profile" sounds like one line. Share to where? Deep link back into what? Preview image generated how? Undefined scope does not disappear - it gets defined mid-build, at the worst possible time.
• Third-party accounts and access. Waiting on Apple Developer enrolment, business verification, a payment provider's underwriting, or someone's IT department to grant API access. Start these on day one; they block launch, not development, and they run on other people's clocks.
• Content and data. The app is finished and waiting on product photos, legal copy, or a seed dataset. Genuinely common, entirely avoidable.
• Mid-build direction changes. Fine and often correct - but they cost time, and a team that absorbs them silently is a team whose deadline is quietly slipping.

Cross-Platform vs Native: The Timeline Difference

If you need iOS and Android, this is the decision with the largest timeline impact available to you.

Cross-platform saves roughly 30 to 40% on the initial build - not 50%, because store submissions, platform-specific work, and testing still happen twice. The larger benefit is compounding: every release for the rest of the product's life is one build instead of two, which over two years matters far more than the initial saving.

Native still wins where you need deep platform-specific capability or absolute graphics performance. For most business and consumer apps in 2026, it does not. Flutter vs React Native covers the cross-platform choice itself, and Flutter app development cost has the budget side.

How to Actually Move Faster

Everything below shortens a timeline without pretending the work is smaller than it is.

1. Cut user roles before you cut features. Shipping one role well beats shipping three roles badly, and it is the largest single lever on the schedule.
2. Use a managed backend for v1. Firebase or Supabase removes weeks. You can migrate later, once you know what you are actually building.
3. Name one decision-maker. Not a committee. Feedback rounds are where timelines quietly die, and one empowered person collapses them.
4. Start store and vendor accounts on day one. They are pure waiting time and they cost nothing to begin early.
5. Write the "not in v1" list explicitly. A scope document that only says what is included is only half a scope document.
6. Insist on two-week demos. You cannot correct a drifting project you cannot see.

Our 90-day MVP playbook is this approach written out week by week, and how to build an MVP in 2 weeks covers the aggressive end of the range and what you give up to get there.

Timeline Red Flags in a Quote

After enough rescue projects, the warning signs in a proposal become fairly consistent:

• A precise number before scoping. "12 weeks" quoted off a paragraph description is a sales figure, not an estimate.
• No design phase in the schedule. It did not get skipped. It got hidden, and it will surface as delay.
• Zero QA time. Same problem, larger consequences.
• The timeline ends at submission. No buffer for store rejection, no stabilisation period.
• Dramatically under everyone else. If three vendors say six months and one says six weeks, the outlier has usually understood the least - and that gap becomes a change request later.

A vendor who tells you a project will take longer than you hoped, and explains exactly why, is giving you more useful information than one who agrees with your preferred date. If you are evaluating teams, our guide to choosing a mobile app vendor covers the rest of the vetting.

A Realistic 12-Week MVP Schedule

This is roughly how a well-run three-month MVP looks in practice. Not aspirational - typical, when scope is clear and feedback is fast.

Note that development occupies weeks 4 through 9 - six of the twelve. Half the project is the work either side of it. Any schedule that treats development as the whole project is understating itself by roughly double.

Frequently Asked Questions

How long does it take to build an app?

Most apps take 3 to 9 months. A focused MVP ships in 6 to 12 weeks, a standard consumer app takes 4 to 7 months, and an enterprise app takes 9 to 18 months. The biggest variable is not feature count - it is how clearly the scope was defined before development began.

How long does it take to build an MVP?

A genuine MVP - one core workflow, one user type, no admin panel - takes 6 to 12 weeks end to end, including design, testing, and store submission. Anything faster is usually either a prototype or a build on top of an existing codebase.

Can an app really be built in 2 weeks?

Under specific conditions, yes: a single workflow, an existing design system, a managed backend, and a client who responds in hours. It produces a real working product, but a validation tool rather than a finished platform. Add payments, multiple roles, or custom backend logic and two weeks stops being honest.

How long does app store approval take?

Apple review is typically 24 to 48 hours and Google Play is often faster - but first submissions are rejected more often than teams expect, usually over privacy policies, account deletion, or missing demo credentials. Budget 1 to 3 weeks for the phase, not 48 hours.

Does cross-platform development actually save time?

Yes - roughly 30 to 40% on the initial build versus two native apps, and considerably more over the product's life, because every subsequent feature is built once instead of twice.

Why do app projects run over schedule?

Undefined scope, slow feedback cycles, integrations that do not match their documentation, and unplanned store rejections. Engineering difficulty is rarely the cause. Decision latency on the client side is the most common single reason a project slips.

How long does it take to build an enterprise app?

9 to 18 months. The code is often no harder than a consumer app - the time goes into security review, compliance, legacy system integration, multiple permission models, and procurement cycles that run on their own schedule.

The Bottom Line

The honest answer to "how long does it take to build an app" is that it depends on four things: how many user types it serves, how many external systems it talks to, how original the design needs to be, and how fast you can make decisions. The last one is entirely within your control and is routinely the difference between four months and six.

The founder from the opening call went with the eight-month quote - and shipped in five and a half, because once we scoped it properly he cut two of his three user roles from version one. The six-week quote was not faster. It was just describing a smaller app than the one he actually wanted.

Want a real timeline for your app instead of a category average? Tell us what you're building and we'll scope it honestly - including the parts that will take longer than you hoped. Get a realistic timeline →