How long does it take to build an app? A realistic timeline

It is September, and the managing director has promised the board an app before Christmas. Nobody has yet decided whether it should take payments, who signs off the design, or whether data should come from the finance system. That is the most common start to an app project we see, and it is also why so many timelines slip. An app timeline is set by the sum of its decisions, and the code is only one of them.

In this guide you get typical timeframes in the Danish market, a phase-by-phase timeline, the factors that delay projects, and a worked example with a concrete booking app. The figures are typical ranges. Your own timeline depends on scope, integrations and how quickly you can make decisions yourselves.

How long does it take to build an app? Typical timeframes

Note the last row. An MVP is fast because it is deliberately small. If you have a new idea, it pays to validate the app idea and build an MVP before planning the full version. That way the following months of development rest on data from real users.

What are the phases of app development, and how long does each take?

Discovery: the shortest phase with the biggest effect

Discovery is the weeks in which you and the supplier decide what the app should do and, just as important, what it should leave for later. Features are written down as user stories, integrations are mapped and the main risks become visible. A week spent here typically saves several weeks later, because the developers do not have to guess. Read more about the format in our guide to a product discovery workshop.

Design: where the idea becomes visible

The design phase moves fastest when one person on your side signs off. Three departments with their own opinions on button colours can easily double it. A clickable prototype is the best tool here: you can tap through the app on a phone, show it to five customers and fix flaws in the flow before a single line of code exists. Changes in a design cost minutes. The same changes in finished code cost days.

Development, testing and launch

Development is the longest phase, but also the most predictable once the scope is clear. We work in short cycles where you see progress every week, and with us you follow the project in the client panel, so you can always see what is done and what is waiting on you. Testing is the phase most often squeezed when a timeline slips. That is a bad trade: bugs that reach users take more time to fix, and they cost trust.

Timeline phase by phase: simple, medium and complex apps

What slows down an app project?

When we look at projects that ran late, the cause is rarely that the developers wrote code too slowly. It is almost always waiting time. Here are the delays we meet most often, in the order we see them:

• No clear decision-maker. When every decision has to pass a committee, a day becomes a week.
• Content arrives late. Copy, images, prices and terms are often the last things ready, and the app cannot be tested without them.
• Access to third-party systems. API keys, test environments and agreements with the vendor of your ERP or finance system can take weeks.
• Scope that grows. Each small extra idea may only be two days, but ten of them are a month.
• Developer accounts. Apple requires a D-U-N-S number for company accounts, and getting one takes time if you do not have it.
• GDPR and legal at the last minute. A data processing agreement or privacy policy first looked at the week before launch can stop everything.
• App Store rejection. A missing test login for the reviewer, an unclear privacy policy or payments outside Apple’s system typically trigger a rejection.

How can you build an app faster without cutting corners?

The single biggest lever is the platform choice. With React Native we write one codebase that runs on both iPhone and Android, so each feature is built and tested once. The second biggest is integrations: we have more than 40 pre-built integrations including e-conomic, Dinero, MobilePay, PostNord and MitID, and an integration that already exists takes days to connect where building one takes weeks.

1. Appoint one decision-maker with the mandate to approve design and scope.
2. Cut the first version down to the one thing the app must do well.
3. Create developer accounts with Apple and Google the day you decide.
4. Request API access to your systems before development starts.
5. Write copy and source images in parallel with the design.
6. Book fixed weekly slots for demos and feedback.
7. Settle the privacy policy and data processing agreement during discovery.
8. Plan testing with 5–10 real users well before launch.

Worked example: a booking app for a service company

Picture a service company with 20 employees that takes bookings by phone and email today. They want an app where customers can book and pay with MobilePay, and staff can see the day’s jobs. The scope is 12 features and one integration, equivalent to a small app package. Here is how the timeline can look when decisions are made quickly:

The result is an app in the stores in about three months. If the MobilePay agreement is only ordered in week 9, or the design needs sign-off from three people, those three months quickly become five. You can compare the price of an app like this with our guide to what an app costs.

How long does App Store and Google Play approval take?

Apple’s review often takes a day or two, but a first submission is fairly often rejected over small things, and each round adds waiting time. Google Play is typically quick, but new personal developer accounts must run a closed test with a group of testers for at least 14 days before the app can be released widely. That requirement does not apply to organisation accounts, which is one reason companies should publish under their own company account. We go through the typical rejections in our guide to App Store approval.

Which red flags should you look for in a supplier’s timeline?

• There is no discovery phase. The supplier is guessing the scope, and you pay for the guess later.
• There is no testing phase, or it is simply called “buffer”.
• Every feature is delivered at once in the final week. You first see the app when it is too late to change it.
• Store approval is listed as one day.
• The timeline does not say what you need to deliver and when.
• A complex platform with several user types is promised in 4–6 weeks.

A good timeline shows your tasks as clearly as the supplier’s, and it has fixed demo points where you see working software. If you are comparing several proposals, see also our guide to agile vs waterfall, which explains how a fixed price and short development cycles can be combined.

How to get a timeline that holds

Start by describing who will use the app, what they need to do and which systems it has to talk to. The more concrete the description, the more precise the timeline. With us you get a written fixed-price proposal within 24 hours, with features and integrations listed, so you can see exactly what is included. Describe your app here, or first see what the packages contain under pricing.