How Long Does It Take to Build a Mobile App?

How long does it take to build a mobile app

A mobile app published on both stores represents 60 to 90 person-days, all roles combined. That is the figure from the public Lonestone rate card for the French market in 2026, and it says nothing about the calendar.

The calendar depends first of all on you, not on how fast the technical team types. A 70 person-day project ships in six weeks or in eight months depending on a single variable: how quickly decisions get made and access gets granted. Confusing the two numbers is the leading cause of disappointment on a mobile project.

Person-days and calendar weeks are not the same thing

A person-day is one day of work by one person. Seventy person-days do not make seventy calendar days.

They can make fewer, if several people work in parallel on independent parts. They can also make many more, and that is the more common case. Four things turn person-days into calendar months:

Waiting for access to a database, a store account, a mockup sign-off. While you wait, the person-day counter is stopped and the calendar keeps running.
Sequencing: some tasks cannot start before others are finished. You do not wire a screen to data that does not exist yet.
Handoffs. Every extra person in the loop adds an explanation, a status report, a response delay.
Rework. A decision that changes after the fact costs the time to undo what was built without it.

Two separate teams, one iOS and one Android, mechanically double the first number. A single codebase compiled for both platforms remains the default call on a business app, precisely for that reason.

That volume of days then converts into euros, line by line, in how much a mobile app costs in 2026.

What actually takes time

Writing the code is not what consumes the calendar. Here is what consumes it, in order.

Decisions nobody made

“We’ll see later whether we add an admin area.” That sentence, said in week 1, costs two weeks in week 5. An app is built in layers: role management is not a screen you add, it is an assumption that runs through the entire codebase.

The cost of a postponed decision is the time to undo what was built without it, not the time to make it.

Your data and your access

If the app has to read from or write to an existing system, everything depends on the state of that system. A documented, testable interface is a few days. A legacy business system with no interface designed for this is a project inside the project, and it starts with getting access from a vendor who has no reason to hurry.

This is the point to investigate first, before the mockups even. A project that discovers in week 6 that the ERP exposes nothing restarts its schedule from zero.

Store accounts

An enterprise Apple Developer account requires a DUNS number. Getting one takes anywhere from a few days to several weeks depending on how responsive the registrar is and the state of your legal information. Google Play requires organisation identity verification.

That delay is purely administrative, it adds nothing, and it blocks publication. It gets started on day one of the project, not the day the code is ready.

Apple and Google review

Count a few hours to a few days for a nominal pass. The risk lies elsewhere, in rejection: an incomplete privacy policy, a missing account deletion feature, a payment flow that bypasses platform rules, a non-compliant screenshot.

Every rejection costs a round trip. Two rejections in a row at the tail end of a tight project, and the commercial launch date slips.

Acceptance testing

This is the phase optimistic schedules delete first, and the one that decides your store rating. Getting real people to test the app on real devices, fixing, testing again: that time gets planned.

A realistic calendar, week by week

For a business app with a tight scope, a single decision maker and accessible data:

Period	What happens	What we need from you
Week 0	Scoping, written scope, opening store accounts and the DUNS request	Your legal information, a named decision maker
Weeks 1 to 2	Flows, key screens, data model, access to existing systems	Sign off the flows, open the access
Weeks 2 to 5	Build, with an installable build delivered every week	Install it and give feedback within 48 hours
Weeks 5 to 6	Acceptance testing on real devices, fixes, store listing prep	Have your teams test it
Week 6	Submission, review, publication	Approve the copy and the screenshots

The right-hand column is the one that decides the outcome. Feedback given within 48 hours holds the schedule. The same feedback given in ten days pushes it back by that much, and five times in a row it has doubled it.

This rhythm also assumes a tight scope and centralised decision making. A project that has to be approved by a committee meeting every two weeks will not hold this calendar, and that is normal: it is a company rhythm rather than a technical problem. You plan around it.

The four things that derail a schedule

Scope that moves mid-project. Every addition is legitimate taken on its own, and it is the accumulation that kills the date. The countermeasure fits in one line: every addition is accepted, and it explicitly moves the date or replaces something else.
Store accounts started too late. It is the dumbest and most avoidable derailment there is.
Access to existing systems. The supplier waits for access, the legacy vendor waits for a formal request, and the business owner learns about the blockage three weeks later.
Group approval with no referee. Three people giving three contradictory opinions on a mockup produce a loop, not a decision. A mobile project needs a named decision maker with the right to settle it alone.

Why some ship in weeks while others take quarters

The difference is not how fast the people are, it is the number of layers the project has to travel through.

In a classic organisation, a decision goes down from an account manager to a project manager, then to a tech lead, then to two separate development teams, then back up to a steering committee. Every level adds a status report, a response delay and a rephrasing. The actual working time does not change. The calendar time is multiplied.

When the person you talk to is the person who builds, those levels disappear: no relay, no billed status report, no translation between whoever heard the need and whoever writes the code. A single codebase for both platforms removes the next level. That is where the speed comes from, and it comes from no tool.

And artificial intelligence, how much does it save?

We get asked this every single time, and the answer does not go the way the market wants: no serious study today measures an end-to-end speed gain on an app in production.

The most rigorous study available, run by METR in 2025, followed 16 experienced developers across 246 issues, in their own repositories. Measured result: they were 19% slower with AI assistance. They had predicted a 24% gain, and afterwards they still believed they had been sped up. The gap between perception and measurement is about 39 points. The February 2026 replication still finds no significant gain.

The famous GitHub “+55%” covers an HTTP server written from a blank page: no existing code, no architecture to respect, no review, no tests, no store review to pass. The study is funded by GitHub. It sincerely measures an exercise that has nothing to do with a client project.

What is measured, on the other hand, deserves to be known by anyone buying an app. The Faros survey of real teams shows merge requests up 98%, but also incidents per request up 242.7%, bugs per developer up 54%, code review load up 441%, and flat final delivery metrics.

For your project, that means this: AI increases the volume of code produced and, mechanically, the testing load. It shortens the path to a stable app in production only if somebody absorbs the extra verification load.

That is why we do not sell a multiplier. We use these tools every day, they are part of the craft, and they appear on no invoice line. The speed we quote comes from the absence of layers to pay for.

When the app already exists and has to be taken over, the schedule starts with an audit and with recovering access, which changes the first phase entirely: taking over a failed mobile app.

What you can prepare to save two weeks

Before you even pick a supplier, these five points are under your control and they are worth about fifteen calendar days.

Start the DUNS number request if your company does not have one. It is free and it is the longest item on the critical path.
Name a single decision maker, with the right to settle things without a meeting.
Identify who holds the access to your existing systems, and warn that person they are going to be asked.
Write down what the app has to unlock, in euros or in hours. Not the feature list: the cost of the current situation. That is what lets you arbitrate the scope when something has to be cut.
Decide now on the three structural questions: are there different roles, do you need an admin area, does the app have to work without a network.

If you want us to look at your case, the scoping questionnaire takes five minutes and prepares a 45-minute call. What we deliver and in what order is laid out on the mobile app page.

Frequently asked questions

Budget 60 to 90 person-days for an app published on both stores. In calendar terms, six weeks is reachable on a tight scope, with a single decision maker and feedback returned within 48 hours. The same project takes six to eight months when approvals go through a committee.

What delays a mobile app project the most?

Structural decisions that get postponed, access to existing systems, and developer accounts opened too late. An Apple organisation account requires a DUNS number that can take several weeks to obtain, and it blocks publication.

How long do Apple and Google review take?

From a few hours to a few days for a clean pass. The real risk is rejection: an incomplete privacy policy, no account deletion, a payment flow that bypasses platform rules. Every rejection costs a round trip.

Does artificial intelligence speed up app development?

No serious study measures an end-to-end gain on an app in production. METR measured experienced developers 19% slower with AI assistance in 2025, working in their own repositories. The Faros survey shows code volume up 98% but incidents per merge request up 242.7%.

Can an iOS and an Android app be built at the same time?

Yes, from a single code base compiled for both platforms. That is the default choice for a business app: two separate teams double the work, the tests and the regressions.

In short

An MVP published on both stores is 60 to 90 person-days. The calendar depends on your decision rhythm.
What takes time: postponed decisions, access to your data, store accounts, review, acceptance testing.
Six weeks is reachable on a tight scope, with a single decision maker and feedback returned within 48 hours.
Organisational layers cost more calendar than the code itself.
AI has no measured speed gain on an app in production. METR measures 19% slower, and Faros mostly measures a rising testing load. Be wary of any supplier selling you a deadline on that lever.