How Long Does It Take to Build an App? A Realistic Timeline, Stage by Stage

A typical conversation I have in September: a shop owner in Vashi wants a customer app “live before Diwali”. That is about eight weeks away. The features are not written down yet, the company has no Apple or Google developer account, and nobody has decided whether customers will pay inside the app.

Can it be done? Sometimes, if the first version is small and decisions come quickly. More often, the date slips, and the reason is not slow programmers. It is the steps before and after the coding: agreeing the scope, getting store accounts verified, passing review, and waiting on third parties. This guide walks through each of those with the official rules and the best public data I could find, so you can set a date you will actually hit.

1. What the data says about app timelines

I looked for a trustworthy survey of how long apps take to build in India and did not find one. Plenty of agency blogs publish timeline tables, but they rarely say where the numbers come from. The most transparent public source I found is Clutch’s Mobile App Pricing Guide, which is based on reviews from clients of app development firms worldwide.

Source: Clutch, Mobile App Pricing Guide 2026, updated September 21, 2026. Based on client reviews on Clutch; no sample size published. Global third-party data, not India-specific.

Read the 11-month figure carefully. It is an average across every kind of project reviewed on the platform, from small apps to large platforms that run for years. A few long projects pull an average up, so it says little about a booking app for a clinic. What it does tell you is that “a few weeks” is the exception, not the rule, once an app does real work.

Clutch also names the two levers that matter: complexity and team size. You control the first directly. The second has limits, because adding developers to a small project often slows it down while everyone coordinates.

2. A realistic timeline by type of app

Since the market data is too broad to plan with, here is the rule of thumb I use when scoping. It assumes one cross-platform app for Android and iPhone, a backend, and an admin panel where the app needs one. It is my experience, not research, and your app may sit at either end of a range or outside it.

Illustrative, based on the author’s project experience. Not market data. Excludes time to obtain store accounts and assumes prompt client feedback.

Notice what the bottom row says: in phases. Large platforms should not launch as one big reveal. Ship the one workflow that proves the idea, then add the rest while real users tell you what matters.

See also: time and money move together, so read what drives app development cost in India alongside this guide.

3. The stages, and where the weeks actually go

Every app project goes through the same stages, whatever the size. The durations below are typical for a small to medium business app and overlap in practice.

Discovery and scoping (1 to 2 weeks)

You agree who the app is for, the features in version one, and what waits. The output is a written feature list, user flows and a milestone plan. Skipping this step is the most common reason I see apps run late, because every unanswered question becomes a pause later.

Design (2 to 3 weeks)

Designers produce every screen and a clickable prototype you can try on your own phone. A change at this stage takes hours. The same change after development has started can take days, because screens, logic and tests all move with it.

Development (4 weeks to several months)

The app, the backend (server and database) and usually an admin panel are built in short cycles, often called sprints. The admin panel is the part owners forget. It is effectively a second product, a web app your team uses to manage orders, users and content.

Testing (1 to 3 weeks, overlapping development)

The app is tested on budget and flagship phones, on Android and iPhone, and on slow mobile data. Payments, logins and notifications get the most attention, because failures there cost money and trust.

Store submission and launch (a few days to several weeks)

Store listings, screenshots, privacy details and reviewer notes are prepared and the app is submitted. How long this takes depends mostly on the account and review rules in the next section, which is why I treat it as its own stage.

4. Store review: what Apple and Google actually say

Owners often plan for review as if it were a single fixed day. It is not, and the two stores behave differently. Here are the official rules, as published by Apple and Google.

Sources: official Apple and Google pages linked in each row, checked October 30, 2026. Platforms change these rules; check before you set a launch date.

Two points from this table catch people out. First, Apple’s speed figures describe a single pass. A rejection means fixing the issue and going through review again, so one rejection can turn a two-day step into a week. Second, Google’s closed test rule adds at least two weeks to launch for anyone on a newer personal account, and finding 12 real testers who stay opted in is harder than it sounds.

A real example from our own work: Apple once rejected an app because the demo login we had given its reviewers had been deleted by an automatic clean-up job on the server. The fix took minutes. The resubmission and second review cost days. Now we protect reviewer accounts on every project.

Apple also allows you to request an expedited review, but only for extenuating circumstances such as a critical bug fix or an event your app is directly tied to. A missed internal deadline is not one of them.

5. The delay that starts before any code: store accounts

The step I most often see left too late is opening the developer accounts. For a company, both stores ask for proof that the business exists, and that proof takes time to obtain.

• Google Play: an organisation account cannot be created without a D-U-N-S number matching your payments profile. Google says obtaining one can take up to 30 days, and payment method verification for paid apps can take up to five more days.
• Apple: companies must provide a D-U-N-S number registered to their legal entity. Apple says to allow up to 5 business days to receive it from Dun & Bradstreet and up to 2 more business days for Apple to receive it. Expediting the request does not shorten the wait. The number itself is free.

One advantage of a company account: on Google Play, the 12-tester closed test rule applies to newer personal accounts, not organisation accounts. The trade-off is the verification time up front. Either way, the accounts should be in your company’s name, never the developer’s. Moving an app between accounts later is slow and sometimes painful.

6. What really slows app projects down

In my experience, the projects that run late rarely do so because of hard technical problems. They run late because of waiting. These are the delays I see most, roughly in order of how much time they cost.

1. Features added halfway through. Each new idea reopens design, development and testing. Keep a “version two” list and protect the launch scope.
2. Slow decisions. A week waiting for design approval is a week added to launch. If three people must agree, it is often more.
3. Late content. Logos, product photos, prices, policies and app store text that arrive in the last week push the launch.
4. Third-party approvals. Payment gateway onboarding, SMS sender registration under TRAI’s DLT system, and WhatsApp message templates all have their own queues. Meta says a WhatsApp template review can take up to 24 hours, and a rejected template starts the clock again.
5. Access to your existing systems. If the app must talk to your billing software, ERP or Tally, getting credentials and documentation can take longer than the integration itself.
6. Store accounts opened at the last minute. See section 5.

None of these is solved by hiring a faster developer. They are solved by preparation on the business side, and that side is yours to control.

7. How to launch faster without cutting corners

There are honest ways to shorten a timeline and dishonest ones. Skipping testing is the dishonest one; the bugs you ship cost more time after launch than they saved before it. These are the honest ones.

Start with one workflow

An MVP is the smallest version that solves the main problem well. For a clinic, that may be booking and reminders, without the loyalty points, chat and video consultations that can follow. Every feature you move to version two shortens design, development and testing at once.

Build both platforms from one codebase

Cross-platform frameworks such as Flutter and React Native let one team write one codebase for Android and iPhone, instead of building two separate native apps. For most business apps, that is the biggest single time saving available.

Consider Android first

For many Indian businesses, launching on Android first is a sensible way to get real users sooner. StatCounter put Android at 93.89% of India’s mobile OS share in September 2026, with iOS at 6.05%. That measures web traffic by device, not paying customers, and premium buyers skew towards iPhone, so check your own website analytics before deciding.

See also: choosing between the two main cross-platform tools? Read Flutter vs React Native.

8. After launch, the clock keeps running

An app is never finished in the way a brochure is finished. Apple and Google raise their minimum technical requirements roughly every year, and apps that fall behind can stop being accepted for updates or stop appearing to some users.

• Google Play requires new apps and updates to target Android 16 (API level 36) from August 31, 2026. Google says existing apps that fall behind on target API level may become unavailable to new users on newer Android versions.
• Apple has required uploads to be built with Xcode 26 and an iOS 26 SDK since April 28, 2026.

In practice, that means a few weeks of engineering work each year just to stay current, even if you add no features. Plan it into your calendar the way you plan an annual audit, rather than discovering it when an update is rejected.

Where this advice breaks down

I want to be clear about the limits of what I have written.

• The only broad timeline data is global. Clutch’s average comes from its own reviewed firms with no published sample size. It shows that serious apps take months, not what your app will take in Mumbai.
• My timeline table is experience, not research. A different team, technology or industry could land well outside those ranges in either direction.
• Some apps genuinely take a long time. Fintech, healthcare and anything handling regulated data may need security reviews, audits or approvals that no amount of preparation removes.
• Store rules change. The review figures and account rules above were checked on October 30, 2026. Apple and Google revise them regularly, and review times vary with the season and the kind of app.
• An MVP is not always right. If you are replacing an app thousands of customers already rely on, a cut-down version can lose them. Then a careful migration plan matters more than speed.

A launch-readiness checklist

Back to the shop owner in Vashi with eight weeks until Diwali. With a small first version, accounts opened in week one and quick decisions, that date is possible. Without them, the honest answer is to pick a date after the festival and launch something that works.