How Long Does It Take To Make An App?
The good news is that there is a scientific process to figure out how long your application will take to build! The less good news is that it requires several specialists to have an intimate understanding of your business model and to analyse each feature your app will include.
But before I unpack how this process works and how you can prepare, you're probably thinking, "that's great, Tim, but I just want a ballpark at this stage".
When new clients asks "how long does it take to make an app"? they're usually not happy when I tell them "I don't know until we do a deep dive", but it's the quickest, most truthful answer.
When they push for a rough estimate, this is the generic breakdown I give them:
- Product Roadmapping - 2 to 4 weeks
- Wireframing - 2 weeks
- Clickable prototyping - 2 - 4 weeks
- Design system & high fidelity design - 3 weeks
- Technical planning and project setup - 1 week
- Developing API and backend logic - 6 weeks
- Building frontend - 12 weeks
- Testing & QA - ongoing
- Client review & user testing - 6 weeks
Some of these activities will overlap. For example, developing the API will happen in parallel with building the frontend. Client review & user testing usually happens while development is still ongoing, and parts of the design system will continually being constructed.
Over the past few years, we've found that small apps will take three months to build with a month of planning at the start. If you skip over the planning stage, then it's likely to be closer to six months.
Wait a second... these timelines don't seem right
The timelines above suck, and they're a poor measuring stick. That's why I try to avoid giving them unless the client pushes.
The first reason they're not that useful is just about every meaningful app development project is run under some kind of agile methodology these days. Unless you're planning to build an ultra simple app with basic features, any technical partner you work with should suggest an agile approach (if they don't, run for the hills!).
Our team runs projects under an agile methology where we design, develop and test a set of features every two weeks. Our clients are constantly providing feedback, changing the scope of what has to be built, and adding or removing features.
In this situation, our clients still want to know when the app will be finished, but that answer is always changing. For instance, if they decide the app needs to integrate with Zapier or Integromat, that will shift our dates by a couple of weeks.
The second big reason the timeframes above aren't useful is they don't take your business idea or feature set into consideration.
There's only one way to accurately answer the question "how long does it take to make an app?" and that's Product Roadmapping.
Product Roadmapping is "the way"
A Product Roadmap is a clear plan to get you from idea to minimum viable product (MVP). It’s a blueprint for your project that bridges the gap between your team and ours.
This is the most scientific approach for calculating your project's development timelines.
Product Roadmapping takes a few weeks and is critical to figuring out how long an app will take to build. Because it's the first step in figuring out all the answers, I will use this section to outline how it works.
The biggest problem with trying to estimate project timelines is that the development company you're working with doesn't deeply understand your business or the project's goals. This results in things being built that don't line up with your team's expectations.
Product Roadmapping eliminates this problem and provides a framework for building detailed estimates. Here's how it works.
Business goals
The first step is to do a deep dive into why you're building an app.
Sometimes the businesses we're working with will brush these questions off with explanations that they're simply trying to improve on current products that do a poor job.
This doesn't help us. We need insights into their business and what stopping them from ruling the world.
Our team have built a ton of applications over the past few years. We've solved problems in some really creative ways. Often, the solution fits the problem much better than our clients expected. If they had just come to us asking for a solution without first unpacking the problem, they would have ended up with a poor-quality app.
To understand a new client's goals, we use a combination of surveys and meetings to ask as many questions as necessary.
We've unpacked this process in much more detail in our extensive guide to Product Roadmapping.
Flows
The next step is capturing the major user workflows. These are the things users want to be able to do with the application.
Using Instagram as an example, a workflow might adding a new image, changing profile picture, or sending a message to another user.
Thinking through the kinds of actions your users want to be able to do with the app is (in my opinion) the best way to capture all features that need to be built.
Features & user stories
Once the major workflows have been recorded, they need to be broken down into smaller bite-sized pieces. Sticking with our Instagram example, changing a profile picture would require these steps:
- Open app
- Select profile
- Select profile picture
- Browse gallery for new picture OR add new image from device storage
- Edit picture
- Confirm
From these workflow steps, we can determine a handful of features like an image gallery, a way for the app to store images, and editing tools.
Each of these features needs to be broken down even further into the way users will expect them to work.
Defining every feature in your app this way means it's had thought put into the way it should work. This is the secret sauce to coming up with an accurate timeline.
Delays in a project are always caused by implementing features that were poorly thought out.
Planning poker for estimates
Once all of the stories have been prepared, it's time for the development team to sit down and provide effort estimates.
Our team handle this through a process called planning poker. During this game, we read through each user story and each provide an estimate on how much effort is required. We'll debate our answers until everyone comes to a consensus.
By the end of the process, we've estimated the entire feature set and can put the number of man-hours down that will be required to build the app!
Planning your minimum viable product features
The final step is figuring out what features will go in the first version of the application.
Getting the v1.0 up as quickly as possible should be the goal here. Sometimes this requires saying "no" to cool features and keeping the feature set simple. Other times, it means doing things manually for a while until the paying customers arrive and inject cash into the business.
Either way, figuring out what features will go into the minimum viable product greatly impacts the timelines. It's one of the main reasons predicting how long the app will take to build is impossible until this process has been hashed out.
Give me a rough timeline
Keeping in mind that you're probably only interested in knowing how long your app will take to build, we'll briefly explain each step in the application development process and how long it can take for different kinds of applications.
You should be able to think through your concept, compare it to our examples and determine a very rough estimate of how long it takes to create an app.
This is how we'll define the size of projects:
Small project
- Simple website
- Chatbot
- Scraping script
Medium project
- Flight and travel websites
- Headless eCommerce websites
- Budget planning application
Large project
- Dating website
- Online medical consultation application
- Any app requiring machine learning or artificial intelligence
Stage 1: Product Roadmapping aka Discovery Stage (1 month)
- Small project (2 weeks)
- Medium project (2 - 6 weeks)
- Large project (2 - 3 months)
Every project should start with a Product Roadmap or a period where the requirements are collected.
When our team undertake this process, we usually schedule at least 2 two-hour meetings to hash out all the details. Then it's a case of building out the process flow diagrams and writing hundreds of user stories :).
The reason this process can take so long is:
- Everyone is busy
- The best way to collect details is in-person meetings
- There's a lot of undocumented information in key stakeholder's heads that needs to be extracted and recorded
Stage 2: Development Sprints (2 weeks, repeating)
- Small project (2 - 3 months)
- Medium project (~3 - 6 months)
- Large project (6 - 12 months)
Development sprints should focus on building a defined set of features every two weeks. During that time, the features will be designed, prototyped, developed and passed back for review.
Building the app piece by piece and sending it back for client review is a cycle. As bugs or new features are identified, they're added to the pile (aka backlog) to be built in the future.
Stage 3: Deployment
- Small project (1 day)
- Medium project (1 - 3 days)
- Large project (1 week)
Once all the features have been designed, developed and reviewed by the business, it's time to deploy the application to production.
This process usually involves some server management, which takes a few hours. The longer process is getting the right accounts up and running, domain credentials configured, smoke testing, and ironing out any last kinks.
A developer told me there are more than three stages!
Some development companies will do things differently.
There's no problem with jumping straight into a full app prototype in Figma so the concept can be visualised. We take this approach sometimes when it's called for.
Similarly, there are times with complex apps when the tech stack and level of sophisticated integrations require most of the application to be built in one big sprint.
Keep in mind with the breakdown above that good apps continue to grow and evolve. Unless you're building an internal tool for a very specific purpose, you'll need to add features, change how things work, fix bugs, and let the app evolve.
So the initial finish line continually gets pushed back once the "first draft" is out the door.
The big variables
Here are the variables that have the greatest impact on your app's development timeline:
Your app idea
I spoke to a potential client a little while ago who was pushing me to provide an estimate for her app.
Her idea was:
- a new social media app that featured machine learning
- would make recommendations based on a wealth of user input
- needed to integrate with the blockchain
- support cryptocurrencies for paying users
- be available as a hybrid app and a web app
- address a range of issues TikTok and Instagram hadn't yet figured out
When asked how long it would take to build, I told her maybe 5 years if we're lucky!
This is an extreme example, but the point I'm making is that the complexity if your idea is the biggest variable to the timeline.
Every feature you want to build takes time. The more complex the feature, the more thought it requires and the longer it takes to design and develop.
Technology stack
As a rule of thumb, mobile apps take longer to build than web apps.
There's no point in building a mobile app if it's not going to work on both Apple and Android devices. And phone chargers aren't the only thing that's unique to mobile devices. Each operating system has unique requirements for the kind of code it will run.
Frameworks like React Native and Flutter have solved some of these problems by allowing one codebase to be written that will run on different devices. Even so, there's quirky behaviour that pops up on different devices.
Getting an android app approved on the Google Play Store can be a bit of a process... but it's nowhere near as bad as getting an iOS app approved on the Apple App Store. There are layers of unclear instruction, heavy restrictions and many hurdles, all of which take time to navigate.
On the other hand, web apps run in the browser. The browser companies have already put the effort into getting their product (Chrome, Firefox, Safari, etc) to work seamlessly across all devices.
Are you building a prototype?
Prototyping is a process of creating static images and then connecting them through a tool like Figma so they feel interactive even though they're just pictures.
App prototyping is excellent for idea validation where it's hard to visualise how different screens and features will interact.
Even if you're following the rapid prototyping methodology borrowed from the physical engineering industry, the process takes time.
Medium applications take a week or two to prototype, but they're not usually the apps that receive prototyping. Larger, more complex apps can take weeks to prototype fully.
Mid project changes
Changing things halfway through a project is the natural enemy to project management. It can cause development timelines to be thrown out the window.
Unfortunately, they're a normal (and necessary!) part of app development.
There's no way to anticipate the magnitude of mid-project changes, which is why we run projects under a scrum methodology, where we anticipate constant change.
Wrapping up
Putting an exact timeline on the app development process isn't impossible, but it's incredibly difficult without knowing all the project variables. The best way to capture these details and figure out a timeline is Product Roadmapping.
Going through the Product Roadmapping process isn't for everyone, and chances are you're probably just trying to work out how long your app idea will take to get off the ground. You can use the rough timelines we've laid out across the article to build an educated guess.
A successful app takes a decent amount of time to build. Getting your product strategy dialled and really thinking through how your app will come together is going to save you a mountain of time and frustration down the line.
Let me know your thoughts in the comments section below. I want to answer your questions in a way that makes sense and don't know if I'm doing a good job unless you tell me!