How long it actually takes to build an app

Timelines slip for boring reasons. Almost never because engineering was slow, almost always because a decision waited a fortnight or the scope quietly grew. Here is what each stage really takes, and where the weeks disappear.

A focused first version takes eight to sixteen weeks from concept to launch. A medium-complexity production app takes four to seven months. Anything enterprise-shaped runs from seven months to well past a year. Development itself is roughly half of that; the other half is deciding what to build and getting it into the stores.

Those figures come from published 2026 estimates and they agree with each other more closely than cost estimates do, which is a good sign. Time is harder to fudge than price. What the ranges do not tell you is which half of the range you will land in, and that is decided almost entirely by things on your side of the table rather than the build team's.

The stages, and what each one really costs you

Add those up and a small app lands around eleven weeks at the fast end. That assumes nothing waits on anyone. In practice something always does, which is why the honest planning number is the top of each range rather than the bottom.

Where the weeks actually go missing

Decisions that sit in an inbox

This is the dominant cause of late projects and it rarely appears in anyone's plan. A build team hits a question they cannot answer alone: which of these two flows, do we support this edge case, whose brand guidelines win. If that question takes a week to answer, the project is a week late, and no amount of engineering effort recovers it.

Name one person who can answer questions within one working day and who does not need to consult a committee. That single decision shortens most projects more than any technical choice you will make.

Scope that grows without the date moving

Adding a feature mid-build is entirely legitimate. Adding it while insisting the launch date holds is not, and the result is usually that the addition gets built and something else gets rushed. The healthy version of this conversation is a trade: this goes in, that comes out, or the date moves by this much. Teams that never say no to additions are not being accommodating, they are being quiet about the cost.

Anything that depends on another company

Payment providers, identity providers, health data permissions, financial data aggregators, and anything requiring an account review or a compliance questionnaire all introduce delay you cannot compress by working harder. Some of these take weeks of calendar time regardless of how quickly you fill in the forms. Start them on day one, not when the feature is ready.

Content nobody was assigned to write

Onboarding copy, empty states, error messages, legal text, store descriptions, and the privacy policy. Individually trivial, collectively a fortnight, and almost always discovered at the point where everything else is finished. Assign it at the start and it disappears as a problem.

The gap between working and shippable

There is a stretch near the end where the app demonstrably works and is nowhere near ready. It is the tail of real-device bugs, the slow network case, the phone with almost no storage left, the user who backgrounds the app mid-purchase. Teams that have shipped before build this into the plan. Teams that have not are surprised by it every time.

A worked example

Take a habit tracker: accounts, a handful of screens, reminders, data syncing to a second device, one platform to start. Medium complexity by any definition. A realistic plan looks like this, assuming decisions come back within a day.

1. Weeks one and two, discovery. What the app does, what it deliberately does not do, and what the first screen looks like when someone has used it for a month rather than a minute.
2. Weeks two to five, design, overlapping discovery at the start. Flows first, then interface. The reminder and empty states are designed here, not improvised later.
3. Weeks four to thirteen, build, overlapping design. Accounts and syncing come early because everything else depends on them and they are where the unpleasant surprises live.
4. Weeks eleven to fourteen, testing on real devices, running alongside the tail of the build.
5. Weeks fourteen and fifteen, store listing, screenshots, privacy declarations, submission.

That is about fifteen weeks, comfortably inside the eight-to-sixteen range for a well-scoped first version. Note how much of it overlaps. A plan where each stage waits for the previous one to finish is a plan for a much longer project.

How to tell early whether you are on schedule

Status reports are a weak signal. A project is on schedule when you can hold it, and not otherwise.

1. Insist on an installable build on your own phone every week, starting as early as there is anything at all to install. Screenshots and demos are not substitutes: a demo is driven by someone who knows which parts to avoid.
2. Watch whether the weekly build changes in the places you expected. Steady visible progress in unexpected areas usually means the plan quietly changed.
3. Ask what is blocked, not what is done. A team that never reports blockers is either not being asked or not being honest.
4. Check that the boring work is happening alongside the interesting work. If error states, empty states and offline behaviour are all scheduled for the end, the end will move.

Sensible ways to go faster

• Launch on one platform. The second platform costs less once the product has stopped changing, and you learn from real users months earlier.
• Cut features rather than quality. A smaller app that works is faster to build and far faster to fix than a larger one that nearly works.
• Use the platform's standard components for the first version. Custom design is worth paying for once you know people want the product.
• Start anything involving a third party immediately, before it is needed.
• Decide the launch content early: store listing, screenshots, privacy policy, support contact.

Ways to go faster that will cost you

Adding engineers to a late project is the classic one and it usually makes things slower before it makes them faster, because the existing team spends its time explaining rather than building. Skipping discovery is the other: it removes a fortnight at the start and adds considerably more later, because the team builds the wrong thing correctly and finds out at the demo.

Skipping testing does genuinely save time in the schedule and spends it after launch instead, at a much worse exchange rate. A crash found in week ten costs an afternoon. The same crash found by users in week one of launch costs a rushed release, a bad review average that takes months to recover, and the trust of everyone who tried the app once.

How we run it

Bridge Softwares works to a weekly build. From the start of development there is something installable on your phone every week, which means the schedule is visible continuously rather than being asserted in a status meeting. Discovery comes first and design before code, because reversing a decision at those stages costs a conversation rather than a sprint.

We also run our own apps, so we live on the other side of every shortcut we might suggest. That tends to make us conservative about the ones that push work past launch.