Right now, I have a hundred apps on my iPhone and none of them are at version 1.0.
All of those apps started at 1.0. Then one of two things happened. Either the app got a great initial response, and that justified continued development. Or, the first version tanked, and that justified continued development.
Either way, for successful apps, 1.0 was just the beginning.
Unfortunately, most companies looking to build an app are not thinking past the initial release. The 1.0 is what they are building and what they have a budget for. Everything they want from the app has been laid out in the RFP.
But this is the worst way to approach building apps because all of the value in an app project will be realized after 1.0. Wouldn’t you want to get there faster, with more of your budget still available to deploy after the 1.0 has validated (or indeed invalidated) your original assumptions?
So, a recommendation: Don’t spend more than half of your budget on 1.0. That’s when the real work starts.
None of the above is app-specific, of course. In the startup space, for example, a whole lean startup movement has emerged around Minimum Viable Products and the key insight that product development is mostly about learning through experimentation. But apps are also unique in a couple of ways.
First, the whole mobile app infrastructure is heavily geared towards thinking about apps in terms of distinct releases. You build a version, do heavy QA on it because it’s not easily updated once out, wait for Apple’s (or Microsoft’s, or someone’s) approval, then release. And then wait for your customers to update. Which some will never do.
Compare this to the web, where leading practitioners push new code to production every day, and it’s no wonder that most people aren’t conditioned to think about app development as a continuous process.
Second, with apps, a monthly release cycle is about as fast as you can reasonably go. A month is a short time in the grand scheme of things, but it can feel terribly long if your app’s current live version is buggy or unpolished. This means that Minimum Viable Apps can be small in scope, but they can’t be lacking in polish. In this sense the bar is set higher in apps than on the web — with web sites, the ability to address customer problems and user experience rough spots in what’s essentially real time means that much less up-front polish is required.
Recommendation two: Trim down your 1.0 by cutting features, not by skimping on polish.
Putting it all together, my rule of thumb is that a 1.0 iOS application should almost never take longer than three months to build.
With this approach, an example project with a six-month scope would be re-cast as as a three-month 1.0 project and three consequent monthly point releases.
Let’s say this app needs to satisfy a dozen distinct requirements. You’d prioritize them and expect to fulfill the most important six in the initial release. The remaining six requirements would then be tackled, two at a time, in the three point releases.
But the fact is that you are unlikely to ever get to those six lower-priority items. By the time you’d be ready to start on them, you will have shipped the 1.0, learned a lot, and have a whole new set of high-priority work to think about.
The beauty of this approach, and the whole point of this post, is that the expected value of that new post-1.0 work is much, much higher than anything you did for 1.0. You simply know so much more about what it is that you’re trying to do.
So get your app past the 1.0. My iPhone is waiting.