By Tobin Harris
Managing Director, Pocketworks
January 15, 2020
Updated January 2, 2024
By Tobin Harris
Managing Director, Pocketworks
January 15, 2020
Updated January 2, 2024
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.
Loads of apps I've worked on take one year to develop. It tends to go like this:
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:
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.
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 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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
We're mobile advisors, investors, and do-ers. We help you deliver positive impact at scale while hitting ambitious revenue targets. Partner with us to hone your strategy, develop apps and platforms, and drive epic growth with mobile. We offer education, consultancy and app development services.
Be the first to read our articles and get fortnightly tips on app research, development and growth.