1 Year in the App Store – when “Move Fast and Break Things” doesn’t work
Yesterday I read Chad Etzel’s experience with his indie games in his post titled My iOS Indie-Game Numbers. In it, Chad generously shares a lot of information about his apps and the struggles he’d had. He also links to Jared Sinclair, who had previously also shared his experience. Both of them are a good read.
This account, my own “a year in hindsight” post, has been in my drafts for a while now as I’ve been postponing it, thinking these mistakes may be too grave, too simple. But then I realized this might be the hindsight talking, and other people may actually benefit from knowing a few of the struggles I’ve had. So, enouraged by Chad & Jared’s shares, I decided to finish this and publish it.
Before writing Rest, I had been working with web technologies almost exclusively for the past 7 years, being out of touch with desktop app development and publishing for a very long time.
“Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.” said Mark Zuckerberg
Then, the “move fast and break things” became a mantra. Often repeated, hanging on posters in offices around the world, embraced by the startup community. I had also been reading The Lean Startup by Eric Ries. Getting your minimum viable product out there, see if there’s any interest and improving on that. And that’s the road I had set to take with my small project.
Almost one year ago, I decided to teach myself Objective-C. Being a bit impatient and curious, I started by looking for a project that was simple enough that I could hack on it without reading Objective-C or Cocoa books. At the time, there was a barrage of articles and headlines regarding our health, tied to the way we spend a lot of our time in front of computers without much physical activity. The New York Times, Forbes, Lifehacker and many others wrote about the issue, so the choice seemed obvious and simple enough to me.
A productive weekend, a few days of hacking on it on the side and it was ready. It was a simple break reminder – and you can read a bit more about how I wrote that first version. Rest – the break reminder was born.
I sent it over to Apple for approval and in a few days I received an exciting email saying that my app was approved! Great! I had decided to sell the app for $0.99, as it was very basic, but also because I wanted to see if I can earn a little bit from it, too, instead of offering it for free. That price point was my first mistake, and I’ll explain why below.
From there, I wrote to a few blogs about the app, and one of them, Lifehacker, mentioned Rest. It felt great seeing your app featured on a popular site and I got 80 downloads that day, which gave me the motivation to continue working on it.
Since I started working on the app and until now, I’ve made a series of mistakes which I’m sharing below. I’ll probably make many more as I continue working on the app, but thought some of this experience may be helpful to others. So here we go.
Mistake #1: Low price point
The first and biggest mistake I made in my opinion was pricing the app too low. It was a simple break reminder, launched in a very quiet way, without any fanfare. Still, apart from leaving money on the table, $0.99 also gets you a lot of impulse buyers – people buying just because it’s cheap. Many of these customers will not really care about you fixing an issue or a bug, but shoot straight to the app store for a bad review. The low price point means they will not care about losing 99 cents, so they won’t even try to work with you to fix the issue. You earn 70 cents per sale, with customers that don’t care about pushing you into App Store oblivion with 1 star reviews. I am genuinely interested in solving those bugs and problems, and shipping a useful app, so seeing a 1 star review is still the stuff of nightmares. Sacha Greif has written a nice post called Why Cheap Customers Cost More. For a few more reasons why your app should perhaps cost more, check out this post by HTTP Watch, where they explain why their app costs $99.99 on the App Store.
Raising my app’s price to $4.99 (after I added a few more notable features) got me nearly no bad reviews, but a constant influx of feedback via the in-app feedback link. Most of the feedback has been great and immensly valuable and even though $4.99 is not much more than $0.99 for most people, it makes enough of a difference to get customers to try and resolve the issue with the app. Some times, it’s been as simple as not noticing the app is running when opening it for the first time, which is a potential 1-star easily averted – and of course, is something I’m now working on, seeing that it might be an issue.
Mistake #2: “Move fast and break things” doesn’t work when you can’t move fast
Getting bad reviews and low ratings can be pretty bad. But most of those problems, especially in a simple app like this, could be fixed in a matter of minutes, or an hour tops. With websites, this can be a very seamless process and pushing a new version to customers can take seconds or minutes.
But the App Store is no website. Even if you have a fix ready for distribution minutes after a complaint, you have to send it to Apple for review and approval. This can take a couple of days if you’re lucky, or up to a couple of weeks if you’re not. In the meantime, the complaints can keep rolling, with nothing you can do to stop it.
Mistake #3: Google AdWords
Since I was a total newbie with AdWords, I accepted a friend’s offer to help. We setup some campaigns, put a bit of money into it and tried to go from there. At the time, there was no Windows version, no iOS companion app. AdWords does not allow you to finely tune your targeting, such as you only include OS X, or only include Windows users. It’s a “desktop + tablets” vs “smartphones” thing, and there’s little you can do to differentiate.
Here’s the data for 1 month worth of AdWords advertising.
Of a total of 133 visits to the website, a whopping 4 (no zeroes missing, almost exactly 3%) visited on OS X, the platform I was trying to target. Android had 20 visits, iOS had 39 and Windows 66. It’s great I didn’t spend too much on this, as it would’ve been a sinkhole. This could be due to misconfiguration or lack of extensive AdWords knowledge, but for me, as a sole developer seeking to promote his product, it didn’t work.
Other mistakes
Apart from the major mistakes above, I can identify a few other areas where things went wrong.
One of them is the Rest app’s website – which after using a few videos from Peek User Testing showed that I actually do a really bad job at explaining what the app does. If you have a website or app, and you haven’t run a Peek user test yet, do it today, it’s free and immensly useful. Insufficient testing also lead to UTF-8 character problems on the new site, which people had no idea what they stand for. For example, all the stars were displaying as textual gibberish, and people were very confused.
Lack of a proper video showing the app in action. A bit related to the above, but a great way to catch people’s attention and really show off your app. A quick demo video I made for the Rest iOS Companion app because Apple’s review team asked for one, caught the attention of Erica Sadun at TUAW. Without a video, I’m probably losing on a lot of potential customers. Currently working on getting this done, though it’s hard to find a person that can do a good job, for a sum that would make financial sense for this app.
Update control is another area where I should’ve been a bit more careful. With most of the updates I’ve sent, I selected to allow Apple to automatically release the new version as soon as it’s approved. But in the last update, this was a mistake. The problem was I also submitted the iOS companion app for review at the same time. Internally, I was hoping that they would get approved at the same time, and I assumed it would happen like that. The new update for the OS X version had a mention of the companion app Rest Beacon, but the problem was, it didn’t get approved soon enough. At least one person wrote to me directly to ask for the iOS app, and probably many more looked for it but couldn’t find it. So to keep things smooth, I’ll probably always choose to release a new version manually after approval. You never know if you’ll find that serious bug after sending for review and best to be in full control of the process.
Other notable things that happened
Of course, not everything was mistakes and problems. Though not a financial success, or revenue you can use to live with, the app still turned a bit of a profit. It got mentioned in a few great websites that brough it quality visitors and customers. First, soon after I made the app, Lifehacker wrote about it. After that, the app got mentioned on One Thing Well (which I’d never heard about before, but actually got me a decent amount of sales). Lastly, though technically out of the “1st year” timeframe, the app got written about in TUAW. Sadly, I was unable to pull in a bit more granular data from the App Store, but I’ve marked the peaks when the app was mentioned in each of the websites.
As you can see, getting press is vital for the sales numbers.
More importantly, users are also fans of the updates and the new features I’ve been working on. Since my initial debacles with the reviews and bad ratings, I’ve worked hard to improve the app and make it truly useful for everyone. It’s been reflecting on the reviews, on the ratings and that also helps with further purchases, as people often base their decision to buy on past reviews. At least one 1-star review got turned into a 5-star review, as a direct result of listening to the customers and fixing any issues they might find.
So here’s to another year in the App Store, learning the nuances and striving for a better app.