How long does it take to build an app?

Founders usually ask this question right after they ask what an app costs, and the two answers are tied together. Time is the biggest driver of price. If you know roughly how long your app will take, you can sanity-check any quote you get and plan your launch around something real.

Below I break down typical timelines by app type, what happens in each phase, what actually slows projects down, and a realistic week-by-week plan for an MVP. The numbers come from how we scope projects at Loha.dev. They are typical ranges, not promises.

Typical app development timelines by app type

The table assumes a small, experienced team building one codebase for iOS, Android and web (React Native with Expo plus a shared backend). Building two separate native apps usually adds time on top of these ranges.

Notice the overlap between rows. A "simple" booking app with three payment providers and a legacy calendar integration can take longer than a social app with a tight scope. Count features and integrations, not categories.

Phase-by-phase breakdown

Every app goes through the same five phases, even when they overlap. Here is where the time goes. For a fuller walkthrough of what happens in each step, see the app development process explained.

Discovery (1–3 weeks)

This is where you decide what not to build. A good discovery phase ends with a prioritized feature list, the main user flows, and a technical plan that names the stack, the hosting and the third-party services. Skipping it does not save time. It moves the arguments into the build phase, where they cost more.

Design (2–6 weeks)

Design can start as soon as the core flows are agreed. Using an established component library and platform conventions keeps this phase short. A fully custom visual identity with lots of animation sits at the long end.

Build (6–16+ weeks)

Development is the longest phase, and it usually runs in parallel with late design work. Backend, authentication, data model and integrations often take more time than the screens people see. Realtime features, offline support and payments each add real weeks.

QA (2–4 weeks, overlapping)

Testing should happen throughout, but plan for a dedicated stabilization stretch before launch: real devices, older phones, bad network conditions, and a beta group using the app for actual tasks.

Store review and launch (1–3 weeks)

The review itself is often fast, but preparing listings, privacy disclosures, screenshots and testing requirements takes longer than most people expect. More on that below.

What slows app projects down

In my experience, apps rarely run late because the code is hard. They run late for these reasons:

• Scope creep. "Can we also add..." is the most expensive sentence in software. Each addition seems small; together they double the timeline.
• Slow decisions. If feedback on a design or build takes a week to come back, the project loses a week. A single decision-maker on the client side makes a big difference.
• Unclear requirements. Building the wrong thing well and then rebuilding it is the classic time sink.
• Third-party dependencies. Waiting on API access, a partner's sandbox credentials, a payment provider's verification, or legacy system documentation.
• Content and assets arriving late. Copy, legal text, product data, brand files.
• Building two native apps separately. Two codebases mean two implementations of every feature and every bug fix.
• Compliance work discovered late. HIPAA, payments, accessibility or data residency requirements found mid-build force rework.
• Account setup. Apple and Google developer accounts, especially for organizations, can need business verification that takes days.

How to ship your app faster

You cannot make good software appear overnight, but you can remove most of the waste. These are the levers that move the timeline the most.

Cut the scope to a real MVP

Pick the one workflow that proves your idea and ship that. Everything else goes on a list for version two. A tight MVP can launch in 6 to 12 weeks where the "full vision" would take 6 months. Our MVP development work is built around this: decide what to cut, launch, then learn from real users.

Build cross-platform from one codebase

With React Native and Expo, one team ships iOS, Android and often the web from shared code. For most business apps this is noticeably faster than building separate Swift and Kotlin apps, with no visible quality difference to users. It is the default for our mobile app development projects. Over-the-air updates for JavaScript changes also let you ship fixes without waiting on a full store review.

Use managed services instead of building infrastructure

Authentication, payments, email, file storage and realtime sync are solved problems. Using a managed backend (we often use Convex for realtime data, and Cloudflare for hosting) saves weeks compared with setting up and maintaining servers from scratch.

Insist on weekly demos

A weekly demo of the working app, on your phone, catches misunderstandings while they are cheap to fix. It also forces fast decisions, because each demo ends with "here is what we need from you this week". If a team cannot show you something working every week or two, ask why.

Decide quickly and have one owner

Name one person who can approve designs and say no to new features. A 24-hour feedback turnaround from that person is worth more than any process change on the development side.

App Store and Google Play review times

Store review is the part of the timeline you do not control. Here is what to expect, with the caveat that both stores change their processes and times vary by app and by season.

Plan for at least one rejection on a first submission. It is common, usually easy to fix, and much less stressful when it is already in the schedule. For the full checklist, read how to publish an app on the App Store and Google Play.

A realistic week-by-week MVP timeline

Here is what a 10-week MVP typically looks like for a cross-platform app with accounts, one core workflow, notifications and a simple admin view. Treat it as an example plan, not a guarantee. Your scope decides the real numbers.

If you are on a new personal Google Play account, the closed testing requirement can push Android launch a couple of weeks past iOS unless testing starts by week 7. Web versions can usually go live in week 9 or 10 with no review at all.

How timeline affects cost

Most development is billed by time, so a shorter timeline is almost always a cheaper project. Cutting scope by a third does more for your budget than haggling over hourly rates. For typical price ranges by app type, see how much it costs to build an app.

The reverse also holds: a very low quote paired with a very short timeline for a complex app is a warning sign. Either features are missing from the estimate or they will appear later as change requests.

When a faster route makes more sense

Sometimes the fastest app is the one you do not build from scratch. If an off-the-shelf tool covers 90% of what you need, start there. Custom development earns its time when your workflow is the product, when you need to own the data and the user experience, or when existing tools force awkward workarounds. That is where custom app development pays back the extra weeks.

If you are not sure which side your idea falls on, get a free app plan. You will get a scoped feature list and a timeline estimate you can compare against any other quote.