In January 2011 I was on summer break, but instead of getting a day job, or socializing, I spent a lot of time holed up in my room writing the first version of an iOS app called Class Timetable. The year before, I’d been looking for a simple, easy to use timetable app, and nothing on the App Store quite fit the bill - everything was too complicated and hard to use. The idea was to create a no fuss, straight forward solution, something that was easier and more convenient than a paper timetable/schedule. Over a few months, I spent about 500 hours designing and coding it. Fast forward to today, and the app has had more than three million downloads, a lot of positive App Store ratings, and at times has been my primary source of income. Haven’t heard of the app? Yeah, it hasn’t taken off yet in the US, but is reasonably popular in Aus/NZ/UK, at least among college and school students.
I’ve read a bunch of blogs recently about people that hit the jackpot, got their app featured, and were looking at figures like 100,000 downloads a day. In comparison, I’ve only been moderately successful. Class Timetable has never made the App Store #1 position, I didn’t become rich overnight, and I’ve failed more times than I’ve succeeded. I’ve invested a lot of time, probably thousands of hours all up, unlike some hit apps that were created in a weekend. Sure, three million downloads is a lot, but that’s happened over more than six years.
Instead, my ‘moderate success’ story is closer to one of hard work, and slow, steady progress. It’s probably more true to real life than other success stories, because let’s face it: not everyone is going to wind up creating the next Flappy Bird. Instead of being a viral hit, Class Timetable has been doing moderately well for more than six years, which is a little special in itself - many #1 apps can’t claim a lifespan that long. I’d like to share a few things I’ve learned over the last few years, so hopefully there’s something here you’ll find useful, no matter how much success you have, or haven’t (yet) seen.
Before writing an app that ‘made it’, I wrote plenty that didn’t make it.
I still think some of them were great ideas - perhaps they just needed some great marketing, or a little luck. There was one called ‘Ginge-O-Meter’ that I put a lot of work into. The concept: take a photo of someone, and find out how ginger their hair is. It used real image recognition and color analysis techniques to deliver an answer, and it actually worked (most of the time). Unfortunately, the idea didn’t catch… I think I made about $50. It was my big shot, and to be quite honest I was pretty dismayed at how much work I put in to see it fail. But I didn’t stop there, and Class Timetable went on to become what it is today. Anyway, my point here is not to hedge your bets. If your winning idea doesn’t succeed: get up and try again, and again… and again, because for all you know your next idea could be the one that makes it.
Design everything around the first time user.
Imagine getting an email in all caps, telling you that you that your app is stuck ‘installing’ and that you need to fix it… pretty frustrating, right? After a few emails like this, you realize that you can never make your product simple enough to use. What I’ve learned (aside from sucking it up, and sending a kind, helpful response) is: design your product as if it was going to be used by people that are a software literacy step below the target user. Keep it simple, make it idiot proof - design everything around the first time user experience. Make sure there’s nowhere people can get tripped up, and that every task has a straight forward, simple workflow. Less time will be spent on support, people will be happier in general with your product, and your ratings will go up. When Class Timetable first started getting thousands of downloads a day, I’d average around twenty emails a week. I’m sure there were other users with the same issues that couldn’t be bothered sending an email, and instead would simply stop using the app. By refining the product areas that led to these emails, I’m now down to an email every two or three days - and most of these are things that aren’t real issues, like feature suggestions, or the occasional fan email (really).
Listen to your critics, but don’t do what they say.
I must have had hundreds of feature request emails from customers, ranging from really good, to very questionable. Now, if I implemented all of those features, the app would be a confusing mess, with 17 background choices, 72 different things vying for your attention on screen, and a settings option for just about everything. Heck, even if I just implemented every sensible idea, the result wouldn’t be too much different. The problem is that even when users can see a genuine product issue, they can’t always see the best solution. So what can we do instead? Listen to your users - to their real, underlying problems - and solve them in a way that takes the product as a whole forward. Sometimes, a great feature suggestion might have downsides for the product as a whole, which means letting it go. This would often happen with Class Timetable: one of its primary features is simplicity and ease of use. While many features have been added to it over the years, a lot of feature suggestions would have made the product as a whole more complicated. Sometimes that was OK, but more often than not I opted for simplicity, the feature that kept it unique.
A great product is better than a viral gimmick.
Class Timetable has never made the App Store front page, or had 100,000 downloads in a day - but that doesn’t matter to me. Some apps reach the #1 spot on the charts, only to become wastelands not even a year later. Perhaps they had a funny quip, viral marketing strategy, or just got lucky - but ultimately, they didn’t have any substance, and they didn’t solve a real world problem in a useful way. By making a genuinely great product, you’re designing something that your users keep coming back to again and again. Put in effort where people might not even notice. Focus on solving real problems, and making a product that is so genuinely useful that your users are coming back and bringing others with them. Returning users is a great sign that your product is healthy. As a bonus, there’s a small viral effect that every active user has, and it’s always great to know that your next customer isn’t just replacing someone that left.
Be generous.
When Class Timetable first went on the App Store, it was a paid $1 download. I figured that for the amount of effort I had put in (~500 hours), $1 was a steal. Anyway, in the first week, 4 people bought the app, and the next week, even less than that. Not sure what it feels like to hit the jackpot, but this didn’t quite feel like it. 500 hours is a lot of time to throw down the drain! I could have left it to die a slow death earning $1 a week, but instead I decided to make the app free. I’d created it to solve a real problem, and I figured that others would find it genuinely useful. Almost straight away, downloads started to pick up. 50 downloads a day, then 100, 1000… wow. Had I held onto the amount of hours I put in and not been generous, I very much doubt that downloads would ever have picked up. Soon after, I added an in app purchase enabling extra features, which now has quite a reasonable uptake. Much higher than a few dollars a week anyway. So, don’t be stingy: a product with no paying users is (usually) better than a paid product with no users. It’s much easier to upsell to an existing customer than it is to find an entirely new paying customer.
Take a step back, often.
Sometimes you’re stuck on a problem, and there just don’t seem to be any great solutions: maybe it’s related to a piece of code you’re writing, or decisions around how you’re going to market your app. Then, you start thinking about the problem from a wider perspective. You realize that you won’t need to even write the tricky piece of code if you architect it the right way, and that the marketing decision is one your friend (who has a knack for that sort of problem) would know how to tackle. You could sum it up as ‘taking a step back’ from the problem. In my entire software career, there’s not a second I’ve spent doing this that I’ve regretted. There’s been plenty of times, especially early on, that I wish I did this and never did. I learned the hard way with Class Timetable: with version 1.0, I spent a lot of time just ‘getting stuck in’ and coding it. I solved tricky problems by cutting corners and ‘making it happen’, instead of taking a step back. As long as users never knew, it was fine right? A year or two later, I had to rewrite the entire codebase from scratch - for so many reasons - which was a massive undertaking. Take a step back! It’s worth it.
Today, Class Timetable continues to do well. I’m always looking to the future, whether that means the next iOS upgrade, or a bigger picture of what Class Timetable could evolve into. If you’re studying at school or college, feel free to give it a go - I hope you find it genuinely useful.