Development Cycle Length: How Long is Too Long?

Matt Hall – Crossy Road

I was listening to the AppMasters podcast with Steve Young that featured Matt Hall, one of the developers of Crossy Road. There was a little nugget in the podcast that wasn’t really expanded on, but I felt really hits on the pulse of the App Store in it’s current form. Matt stated that the development time for Crossy Road was about eight weeks with three core team members. Why is this significant? How long should a development cycle be for your average iOS developer?

Let’s Compare

On the flip side of the Crossy Road development cycle length is Monument Valley. Monument Valley was in development for 55 weeks and is estimated to cost around $852,000 with eight core team members. Both apps have been a huge success. On January 13th, 2015 the Guardian reported Crossy Road had made over $1 million from ads alone since November 2014 or about $350,000 a month. Monument Valley, according to Tech Crunch, has made over $5.8 million since April 2014, or about $680,000 a month. Both took different approaches regarding development length. The Crossy Road team didn’t want to take the chance on spending a year in development for something that may or may not stick. Monument Valley had a larger team and more money to spend, mitigating their risk. Both teams took on risk, but in different measurable ways.

Minimum Viable Product

Shipping the minimum viable product minimizes your risk by getting your app in the store without investing in too many features or dragging out development. That doesn’t mean you don’t polish your app or ship before it’s ready. It just means you can’t spend your time adding a bunch of features when you don’t even know if your app will have any success. It is increasingly easy for a well done app to be lost in the App Store shuffle. If you don’t nail the marketing AND have a great app, it’s very difficult to sustain any kind of success.

As you are working on your app, you’ll be thinking of all the features that you need to have. In my experience, you can throw out at least half of them for the first release, probably more. Work hard on polishing the core functionality. Think of the problem your app solves and focus on that. If a feature isn’t needed for the app to solve the problem, save it for a future release or drop it altogether. Apple likes simple. Users like simple. If your app solves the initial problem and finds any success, users will lead you down the feature path. Paying attention to features actually needed shortens the development cycle and minimizes the risk that you may be spending all your time on something that isn’t a viable product.

Do You Really Need That Feature?

Marco Arment has talked extensively about his podcast app Overcast on the ATP podcast. When it was first released, the big knock I heard everywhere was that it didn’t support streaming. A podcast app that doesn’t support streaming? Seemed odd. Not supporting streaming out of the gate had to do with how he was implementing his groundbreaking Smart Speed feature along with limitations of the streaming framework. Marco had revealed earlier that he knew this was a must sought after feature that he planned on implementing. At some point along the way, however, he came to realize that streaming wasn’t actually as in demand as it appeared. Most of his support emails were less about streaming and more about being able to save podcasts you’ve already listened to. So Marco has shifted gears and now has no timetable or commitment to offer streaming. I think it’s a good study in assuming a feature is crucial for survival when it actually isn’t. I remember thinking when I first downloaded Overcast that I wouldn’t end up using it because of the lack of streaming. After a week or so, I realized I didn’t miss the feature and have been a happy Overcast user ever since. Not only did Marco leave this seemingly obvious feature out of version 1.0, he has learned it’s actually not in as much demand as originally thought.