How long does it take to develop an app?

App projects are notorious for running late, but it's only fair that you want to know how long it will take to develop your app. Since there is no one-size-fits-all answer, the most useful thing I can do is give some examples that might be relevant to you.

When most people talk about developing an app, they actually mean planning it, developing it, releasing it, fixing issues. So that's what I'll cover in this article. 

I'll start by discussing the one year app, and then talk about why you should try and do something in four months.

Most apps take one-year to develop

Loads of apps I've worked on take one year to develop. It tends to go like this:

• Months 1-3: Figuring out what to build
• Months 4-8: Building stuff and testing it on people
• Months 9-12: Ironing out niggles and doing a full release

At Pocketworks, this is based on a team of three developers: a designer, a tester, and a product owner. The designer and tester are usually working part-time.

You can usually build a reasonably complex app in this timeline. By that I mean:

• Connected to some of your businsess systems via APIs
• Accounts and user login
• A hand full of features
• Some backend infrastructure to support all this

For even more complicated apps, you can add a few extra team members and get even more done. Just remember that productivity goes down as you add more people.

There are more examples around this one-year timeline below, but first let's talk about the four-month timeline.

You can do a lot in four months

I often talk about how I hate one-year app development projects because you just don't have to wait that long to get something into customers hands. If you have a clear goal, a good team, tight collaboration and communication, and are willing to accept different solutions to how to achieve your goal, then you should be able to create something useful in 3–4 months.

This means you need a smaller scope and a looser specification. If you're able to cope with an agile project, then this should suit you down to the ground.

Technically, you can move faster than that, but there is always a bit of "warming up" time needed, as discussed below.

The first release takes longer

The first release of your app might take 3–4 months because starting software projects can be a bit “messy” as people rally around and things ramp up. Here are the necessary starting activities that take up time.

• Aligning everyone on goals, risks and ideal outcomes
• Researching the needs of customers and staff 
• Creating ideas, sketching and shaping the solution 
• Gathering feedback and input from stakeholders and customers/staff
• Researching technical risks, integrations and the business domain
• Clarifying the elements that need designing and building and resolving issues that might impede development

This can take hours, days or weeks depending on the size of your project. With that nailed, we’re all in a good position to start building an app.

After this, you can move to shorter cycles. So, after the first 3-4 months, you might release the 2nd version of your app 4-8 weeks later.  

Thinking in time-boxes can help

Another reason to assign 3-4 months is that it’s a time-box to work towards. It’s changing the question from “how long will an app take?” to “how can we move toward our goal in 3-4 months?”. 

This is a healthier question to ask because you’re limiting the risk by setting shorter milestones. Yes, you might not get everything done, but you should get something useful done that will start generating revenue or saving money, depending on your goal. 

If you like the sound of time boxes, you should check out the Shape Up method, it's pretty cool.

How to stop a 3-4 month app becoming a 6-12 month app

There are things that will make your app take longer, and in turn cost more. The more you can minimise these factors, the less time your app will take.

• The people managing the app in your business have too many other things to do. This means that things that should take a few days drag out for a week or so as people wait for information or answers to questions.
• There are other systems to integrate with. There are many risks around integration that make projects take longer. We recently did an integration with Sage that should have taken weeks but it ended up introducing a three month delay just waiting for the work to be done in preparation for the app.
• The team doing the work are pulled off onto something else. This sounds obvious but it’s important your app developers can commit consistent effort to move your app forward.

What does the data say?

I’ll also talk about something a bit more useful – our own history. We build apps for a living and capture data along the way around how fast they progress. 

I reached into our systems and pulled out some stats about how long it’s taken us to build some of our apps and what influenced the timelines.

The charts below show the amount of software delivered over time for a given project. 

App #1 – seven months

Here we have a 3-4 month app designed to help customers have an easier time at an “experience day”. In the end, it took seven months. You can see that progress stops when the busy management team are pulled away on other pressing priorities. Then, when they come back, things ramp up again. This highlights the importance of having a consistent focus on both sides if possible. Without it, progress can halt, adding months to the delivery timeline.

App #2 – twelve months

This app helps 100 drivers work more efficiently in the construction industry. It had a six month delivery timeline but ended up taking 12 months. We had a strong start and made good progress from September to December. Christmas slowed things down, naturally. After Christmas, the business leaders were pulled away on other challenges. Then a lot of time was spent waiting for the Sage integration to get up and running between May and July. This highlights how integrations with other IT systems can slow things down, and also the need to allocate someone in the business to keep the app moving along.

Healthy conversations to have about the app development timeline

Nobody has a crystal ball at the start of the project. It’s difficult to foresee all the risks that can make an app take longer. The most useful thing to do is to first speak openly about things that can go wrong, and also run a discovery phase aimed to establish the risks. Conversations about these kinds of things are healthy ones to have early on:

• How available are people on the development team and the business side of things? 
• Which single person is assigned to “own” the project from the business side?
• What is the smallest thing we could build that gives value? 
• What pain points are customers really having? What if we just address those?
• What IT systems are there and where does information need to flow? 
• How much capacity does the development team have?
• What is their lead time?
• What upcoming events and holidays could derail progress?

In summary, different app projects take different amounts of time. The best thing to do is to set key milestones, be honest and open about anything that might delay the project, and readjust the timelines accordingly. This means everyone is on the same page and timescales can be re-estimated, expectations managed and products delivered. 

What about no-code tools to speed things up?

You can shorten timescales by using no-code tools. For example, shaving of 30% is a reasonable starting point. However, this comes with a warning. No-code tools are good for exploring ideas or testing a concept, but at some point you're going to want to switch to native app development to get the results you need. 

Hope this was helpful. Feel free to contact me on Twitter (@tobinharris), LinkedIn (@tobinharris) or by email (tobin@pocketworks.co.uk ) if you’d like to chat about any of this.