How long does it take to build an app? Where the time actually goes

"How long will it take?" is the second question every client asks, right after "how much?". The honest answer is that it depends on less than you think on the amount of code, and more on things that happen outside the code.

Here is where the time on an app project actually goes, phase by phase, and what stretches each one.

1. Deciding what to build

Before any design, someone has to turn the idea into something buildable: who the users are, what each of them can do, what the rules are, and what is not included.

What stretches it: decisions that nobody owns. If three people must agree on every screen, this phase takes as long as their calendars allow. The fastest projects have one person on the client side who can say yes.

Why not to skip it: every question left open here comes back later, in the middle of development, where answering it costs rework instead of a conversation.

2. Design

Wireframes first, then the visual design, then a clickable prototype you can put in front of real users before a line of production code exists.

What stretches it: revision loops without criteria. "Make it pop" can go around forever. Agreeing up front on what the design must achieve, and who approves it, keeps this phase short.

3. Building

The part everyone pictures. For most apps, it is the largest single phase but not the majority of the calendar.

What stretches it:

• Integrations. Payment gateways, maps, SMS providers, government or banking APIs. Each one depends on someone else's documentation, sandbox and support team. A single slow integration can hold up a release on its own.
• User roles. A customer app is one product. A customer app plus a driver app plus an admin panel is three products that must agree with each other.
• Changes mid-build. Not because changes are bad, but because each one ripples into screens that were already finished.
• Content. Real text, real images and real product data. An app waiting for its content is not finished, however complete the code is.

4. Testing

Testing happens throughout, but there is always a final round on real devices, with real data, by people who did not build it.

What stretches it: device variety. Android in particular runs on hundreds of screen sizes and OS versions. Deciding early which devices you actually support keeps this phase bounded.

5. Store submission and launch

Apple and Google both review apps before they go live. Reviews are usually quick, but a rejection means a fix and a resubmission, and first submissions are rejected more often than later ones. Missing privacy policies, unclear account deletion, test accounts that do not work and screenshots that do not match the app are common reasons.

What stretches it: starting the paperwork late. Developer accounts, business verification, store listings and privacy documents can all be prepared in parallel with the build. Teams that leave them to launch week lose days they did not need to lose.

The delays you control

Most schedule slips on app projects are not engineering problems. They are:

• Waiting for decisions. The single biggest one, on almost every project.
• Waiting for access. Accounts, API keys, servers and brand assets that only the client can provide.
• Waiting for content. Text and images promised "for next week".
• Scope arriving late. Features that were always wanted but only mentioned once building started.

None of these is a criticism. They are simply the parts of the schedule that sit on the client's side of the table, and they are the parts you can shorten.

A better question than "how long?"

Instead of asking for a number, ask for the plan: the phases, what each one delivers, what the supplier needs from you and when, and which assumptions the timeline depends on. A timeline with its assumptions written down can be managed. A bare number can only be missed.