John's Adventures

Back in September 2014 I released John’s Background Switcher to the Mac App Store. The idea behind the Mac App Store is that you pay £60 / year to Apple so that you can sign and distribute software for the Mac and submit apps for sale there. Apple host it, handle shipping updates to customers via the standard software update mechanism and your app appears on the App Store application bundled with OS X. Oh, and Apple take a 30% cut of every sale you make.

It sounds great. The App Store is built into every Mac. That’s potentially millions of customers wanting to buy your software! And unlike the iOS app store there isn’t an expectation that apps are priced unrealistically at $0.99 where there is no hope of ever covering the development costs, never mind making any money. However I had more modest goals than becoming rich and giving up my day job. I just wanted to cover the bare cost of building JBS. So I figured I’d break it down and detail how it’s panned out over the last 9 months.

The Costs Of Building An App

But first, development costs. I already mentioned the £60 / year to Apple. In addition JBS is built using Xamarin.Mac which for the cheapest Indie license costs $300 / year (call it £200). The website you’re looking at here costs £60 / year to host on WordPress.com and Amazon S3 hosting (not all directly related but a cost I’d want to cover) is maybe another £30 per year. I also support Interfacelift (a lovely photo site that has a paid-for API) and that costs me £19 / month or £228 / year. So that’s £578 per year recurring fixed costs.

Next is time. JBS for Mac took me 4 months of evenings and weekends (often very late into the night) to build. I’d conservatively estimate (knowing it was higher) an average of 4 hours, 4 nights per week and 8 hours at the weekend, which is a total of 384 hours work. Apparently an average hourly rate for a developer is £37.50, so let’s say to hire someone to build it for me would have cost around £14,400 (or $22,000 USD). Plus I’d have still had to spend my time managing, testing, designing, etc. Fortunately I could re-use a good portion of code from the Windows version of JBS, otherwise those numbers would have been a lot higher. However I had no expectation of ever making a dent in those costs – JBS is something I’ve loved building for years so it’s never been about the money. Instead my goal was to cover the fixed annual costs of £578 (around $880 USD). If I could make that I’d be happy.

I decided to take the same marketing approach I did with JBS for Windows which is to not advertise it, chase reviews, hound techie sites for kudos or such like. I’d leave it to grow organically, which meant I could iron out bugs while the number of users is small and if it ever gets successful then it’ll be a lot more stable and solid. In short, this is what happens when you build an app for the Mac App Store and are too lazy to do any marketing or advertising – the “build it and they will come” philosophy. (My brother works in marketing so will likely cringe at this approach). If you put in any marketing effort then expect to do better than me – this is like a baseline case study.

The Numbers

So come on John, how much did you make? Are you rich? The answers are “Ok…” and “no”. After some tinkering I decided to set the price at £6.99 / $8.99 as it felt about right compared to other apps out there. And without further ado, here are my sales from launch mid-September 2014 to June 1st 2015:

I average around a sale of JBS per day and over the past 9 months I’ve earned $1840, or £1200. Knock off tax at 40% (worst case scenario) and that’s £720. So that pays the development costs for a year with enough for a couple of meals out – yay! Although if I never write another line of code again for JBS it would take me 15 years to recoup the initial development costs alone. Clearly I won’t be quitting my day job any time soon! It’s fortunate that JBS is a passion project rather than a source of income. When you look at numbers like this and understand the amount of work that goes into building what seems a pretty simple app, it can be particularly galling to read reviews like this:

Which leads me nicely onto…

Why The Mac App Store Kinda Sucks

Ah yes. So 30% cut aside, there are a lot of downsides to selling on the Mac App Store. The first of which is the review time. It varies, but on average it’s taken around 7 days from submitting my “ready to go” app to Apple before it’s actually reviewed. And if it’s rejected (which it can be for a vast array of subtle reasons) you go to the back of the queue and have to wait another 7 days for the next one. This has happened many times with me and their rejection explanations can be so vague that it takes several go-rounds before you get to the bottom of it. Here’s the process for the next version (it’s currently June 3rd as I write this):

So if you’re used to being able to ship updates quickly, you’ll find the Mac App Store infuriating.

Update: As of January 2017 the review time is around 1-2 days which means rapid releases can be achieved through the Mac App Store – certainly a good thing in my book. However…

The next problem is that the App Store app itself is truly awful. It’s difficult to discover applications, the search is next to useless and it highly favours apps that have been “Featured” by Apple. I’ve no idea what gets an app “Featured” and that’s part of another problem – it’s a black box. If you’re not featured you have no control at all over your app page – and since the app pages make finding the support link difficult you often end up with app reviews like the one above. If you sell direct you get an angry email you can actually reply to and help the person out. And with no option for people trialling your app, if it turns out someone bought it thinking it was something else, all you’ll get is a 1 star review for your troubles. For a company that prides itself on attention to detail, Apple have done a really shoddy job with the Mac App Store.

But I guess investment goes where the money is. As Sam Soffes wrote, it doesn’t take a lot of sales to get to the top of the charts which shows that despite shipping on every Mac, the percentage of people who actually buy on the Mac App Store must be very small indeed. You can see the app store charting for JBS here.

Time To Sell Outside The Mac App Store

Having no control at all over the presentation and sales process, not to mention glacial release times and no direct contact with users who’ve bought the app, I felt I really should explore selling outside the Mac App Store. So I’ve set up a shop with FastSpring who do this sort of thing for loads of other app vendors. While their commission is lower than Apple (which let me drop the price a bit), my primary motivation is to provide the best service to users of JBS.

To do that I need them to get a personal email when they buy a copy that gives them a point of contact should it not meet their expectation. If they hate it, I want to see if I can help them by making JBS better and if not give them a refund, no worries. I don’t want to be seen as some faceless corporation which is partly why the app store mentality can kick in with perfectly reasonable people who end up leaving reviews like the one above. I also need to be responsive by fixing issues and adding new features quickly. Having to wait weeks to release an update in the 21st century is just unacceptable, so by using Sparkle I can push out updates whenever they’re ready to go.

I’m leaving JBS for sale both in and out of the Mac App Store. I wouldn’t want any of the 285 people who’ve bought it to miss out on updates, it’s just they won’t be shipped to them as quickly as for people who buy direct. Of course if anyone bought it from Apple and want a non-sandboxed copy I’ll happily sort out the license for them since happy users is my primary motivation, not making sales. And being outside the Mac App Store gives me more flexibility to make that happen.

I’m planning on adding trial functionality so you can try out JBS for free and if you like it you can then buy it, but that’ll take a little time to implement. However at least it’s now an option outside the Apple walled garden.

Next Steps

Firstly I’ll see how sales go outside the app store and if being more responsive helps spread JBS by word of mouth in the same way the Windows version has. But it does show that it is possible to sell an app without doing any marketing at all, just not necessarily to make a decent amount out of it. I’d be foolish not to look at marketing JBS to see what impact that has, so any suggestions welcome. 🙂

Further Reading

If you fancy filling your Mac desktop with beautiful photo montages then you can now either buy it on the Mac App Store or directly from my store. You’ll find the latter is a bit cheaper, you’ll get updates faster and… Wait, if you’re here you’ve read all of the above so no need to repeat it! And if you want to read a bit more about JBS and what it does in general, here’s the product page.

If you haven’t come across it before, xkcd is, to quote the site itself “A webcomic of romance, sarcasm, math, and language” and it’s highly entertaining (my personal favourite is this one about security). Anyway, a recent comic, titled “Now” shows what is effectively a world clock that live-updates so you can see, anywhere in the world, if it’s a good time to phone a friend or colleague. At the time of writing it looks like this:

Now what if you wanted that clock on your desktop, live updating so that all you need to do is look at your desktop and know if phoning your friend in Bora Bora will wake them up from their peaceful slumber? If you’re a Windows or Mac user then it’s easy with the use of my beloved John’s Background Switcher, and it’s simple to set up.

Just head over to the download page and install it. Then when the settings dialog comes up just choose “Add” then “RSS photo feed” (stick with me, it’ll make sense). Then copy and paste the following URL:

http://imgs.xkcd.com/comics/now.png#1

Do the same again, but this time copy the following URL instead (note the 2 instead of 1):

http://imgs.xkcd.com/comics/now.png#2

If you have more than 1 monitor, add some more feeds, just change the number at the end of the URL accordingly. In case you’re wondering why, it’s that JBS doesn’t want to show you the same picture twice in a row, but this tricks it into treating them differently each time. Note to self: fix that in a future version.

Next set up JBS so that it centres the picture and switches every 15 minutes like so (the Mac version is slightly different, but you get the idea):

JBS will automatically pick a complementary background colour (usually white here) but if you want to hard-wire it to a particular colour go to the “Picture Handling” section and choose “Use a custom colour for picture borders” then pick white.

Since you patiently looked at the screenshot above you’ve already set JBS to change every 15 minutes and centre the picture, so that’s it, the world clock will always be up to date! How cool is that?!

Thanks to JBS user Mårten for suggesting the idea in the first place!

I’ve been writing software professionally since 1996, although I started writing code many years earlier for fun. I’ve never been interested in getting professional qualifications or certifications in software development, I’ve always figured the best way to reach your potential is to work with people better than yourself (so you can learn how they work) and actually build and ship software to real people, then deal with the fallout that brings (the try, fail, improve, learn cycle I’ll get to later). A piece of paper is no substitute for experience.

However some of the most useful lessons I’ve learned have not been doing the work I’ve been paid to do, they’ve been learned working on software I give away for free.

I’ve been very fortunate that my freeware software John’s Background Switcher has been dramatically more popular than I could have imagined back in 2004 when I first created it – I stopped counting at the point when hundreds of thousands of people were using it. Fortunate not for the reasons you might think – it’s definitely not a case of “whoa! look how many users I have! I’m awesome!”. It’s been great because I’ve learned more about software development, shipping software and above all humility working on JBS than I ever have professionally.

Prior to JBS it was easy for me to forget that real people actually used the software I wrote. I would focus on writing the code for a feature, being as clever as I could be to impress my developer peers, completing it, then moving onto the next thing. I would pretend all that mattered was the thing I was currently working on – “leave me alone, I’m in the zone!”. I thought that users didn’t have a clue what they were talking about and if they complained then it was them who were in the wrong, it was “user error”. WHY DON’T THEY UNDERSTAND?!

The Techie User Phase

JBS was originally written for exactly one user – John Conners. I wanted a simple tool to periodically change my desktop wallpaper (and recover from my friend Ben setting my wallpaper to that of a monkey whenever I left my desk) – I was scratching my own itch. Then I released it for the world and… nobody cared at all. Later I added Flickr functionality and suddenly I had a bunch of people I’d never met, mostly techies like myself, using JBS.

They had suggestions of how to make JBS better. Since JBS didn’t do a great deal it was easy for these technically savvy people to pick up how it worked and the more ideas and suggestions they came up with, the more I added. Sometimes I’d break things, the users would tell me and I would fix them. It was great to be able to just do what I wanted without having layers of managers to persuade feature X should be in the next version. It was freedom!

Soon JBS supported several different picture sources, had lots of options to do things like exclude certain pictures, view the originals, change the way pictures were selected and so on. Things were great! Until it got popular and my ego took a battering.

New Users Aged 8 to 88

Thanks to word of mouth and some write ups on big technical sites, more and more people started trying out JBS. While early users were technically minded like myself, a lot of people with comparatively little computing ability were starting to try it out. And they were getting horribly confused.

In my haste to add functionality I’d stopped trying to keep JBS simple to use so when you first started it up it was by no means clear what JBS did, how to configure it or just what the hell was going on. So people would often email me with one line sentences complaining. I’d then have to reply and find out what the problem was and to me it would be incredibly obvious what they needed to do, but to them it may have well as been written in Klingon. However that was only scratching the surface. A great deal more people installed it, tried it, uninstalled it and I never knew anything about it.

I’m John Conners, What The Hell Do I Know?

Deny it all you like, but developers have egos. I’m no exception. You think you’re smart, you create things with your mind and hands and when you hit “Build” people should kneel before you in awe. But the reality is people just want to do their job, whatever that may be, and they don’t want things, like your software, getting in their way. If they want something that changes their desktop wallpaper, they just want it to do it and work the way they want without them having to think about it. End of story. The best software is the software you don’t even know you’re using – because the software itself isn’t the objective, it’s the task someone wants to accomplish (like writing a blog post like this) that matters. It took me a long time to realise this fact, but let’s rewind a bit.

I decided to add a feature so that if you uninstalled JBS it would show a web page that asked you if you’d like to tell me why you’re removing it. It was both a great idea and a tough pill to swallow. Because what happened is people actually told me why they were uninstalling JBS. And it turned out it was all my fault.

By this stage if JBS crashed it would send back a crash log to my FogBugz instance so I could figure out any bugs in JBS or any of the components it depends on and fix them. This taught me to write the simplest code possible. There’s a tendency for developers to try to show how clever they are by writing needlessly complex code and I was no exception. But overly complex code is likely more prone to bugs and when you come back and look at that code to figure out what went wrong the fact that you wrote it is no help, you look at it and think “why the hell did I write it like this and what is it doing?”. Lesson learned – write the simplest code possible so that when you later come back to fix it (everybody creates bugs) it would be easy to figure out what it was doing.

Uninstall feedback was a revelation. All of a sudden I was getting into the mind of the people who’d tried JBS, been confused by it, not been able to get it to do things it actually could do, then uninstalled in frustration. Some of the feedback would be, shall we say, tetchy. I quickly stopped taking it personally as when software doesn’t do what you want and gets in the way, it can be frustrating.

I actually changed the feedback page to say “Remember, I’m a real person called John and not some faceless corporation so be nice!” which snapped people out of being particularly mean and the feedback became a lot more useful. To those who say you should make software impersonal, you’re talking nonsense!

It didn’t take long before I could see patterns. What I thought was intuitive was clearly not. I could explain to those who left their email addresses how to do what they wanted (since JBS was loaded with features by now) and that helped them out individually. But the real problem was people running it for the first time and getting lost. I needed to rethink how I did things.

Try, Fail, Improve, Learn, Repeat

So I had a reasonably successful software product. I had tens of thousands of users. I had a large number of feature requests. And I had a lot of feedback telling me I needed to make it simpler for new users to use, but I didn’t want to sacrifice functionality. I decided to take a step back and do some planning. So I contacted a bunch of the most passionate JBS users (i.e. the ones who complained the most) to run some ideas past them in a bid to get into their heads, understand what they were expecting and see where that led me.

One of the main problems was that JBS had a whole bunch of different photo sources and it treated each one completely differently. It was not obvious for a new user what to do and even if they added some picture sets (some folders, Flickr sets, etc.) it still wasn’t clear what was actually happening. I’d originally built JBS to use local photos, then added Flickr, then a bunch more sources and had just bolted them on one after the other. People just wanted to choose some photos and get on with it, and no messing around!

So I started by doing the exact opposite of what I was used to. I started removing features.

I knew this would inevitably annoy some JBS users, they’d complain and might stop using it. But I suspected that if I did my job right it would alienate a few users but help a great many more. I had to go with the majority because much though I enjoyed answering emails and helping people out, it would be easier for all concerned if JBS was so easy to use that it required no help from me.

By now whenever someone emailed me I would ignore anything positive they’d say and focus on anything negative, always assuming that their problems were my fault – if you can’t use it it’s because I didn’t make it easy enough to use. This approach has the useful effect of disarming people because many would start by saying “I must be stupid because…” so me telling them they weren’t took that frustration away. I was now learning how to be a support person.

So I completely redesigned the user interface of JBS in consultation with the people who actually used it. I opened up early beta testing for anyone who was interested and would let them try it as I developed it, putting up builds every couple of days, seeing how my changes came across and letting them guide me how to go from there. I was quite happy to work on a feature for days only for it to fall on its face and end up deleting it completely – I took my ego out of the picture. I would try something, see how it worked and either remove it, change it or keep it depending on how it worked for real people. I would start from the position that I didn’t know best, I would let the JBS users tell me what they wanted and try to do it to provide the most benefit to the most people without compromising the simplicity I wanted it to have.

I also learned to start saying “no”. An idea can be a great idea, but if it made the software more difficult to use for 99% of users just to help 1% then I wouldn’t implement it. But rather than throw it away I’d see if there was another way to achieve what the person suggesting was after. Quite often there would be since as any sales person knows, people may know what they want, but might not know what they actually need, you just have to make them realise it and provide it. So I wouldn’t say “no”, I’d say “how about if I did this instead?”.

The Proof Of The Pudding

So after a hell of a lot of late nights and long weekends I released JBS 4.0 and an interesting thing happened. The feedback was initially very quiet. Which to me was perfect. As I had come to realise, good software doesn’t jump out and shout at you and make itself noticed. Good software should be practically invisible, quietly doing its thing and letting you get on with your primary tasks (which I assume is posting on Facebook, which JBS supports of course!). I took it as a great compliment that while user numbers kept increasing, the number of uninstalls and uninstall feedback dramatically reduced.

The JBS 3.6 User Interface

The JBS 4 First-Run Experience

The JBS 4 User Interface

Over time though I’ve received a flood of correspondence that makes all those countless hours of work for no financial gain more than worthwhile. People telling me how they hate their job but when they’re down they look at their desktop to see a montage of photos of holidays with their family, they smile and get on with their day. People who’ve installed JBS on their parents PCs pointed at their Flickr feed so they can keep up to date with what their grandchildren are doing. Even people who’ve lost a loved one but remember happy memories when they pop up on their screen. Touching people’s lives in a profound and positive way is rewarding in a way money can’t buy and thanks to all the lessons I learned above, I was able to make it happen.

A Summary In Neat Bullet Points?

Normally I’d write a bullet point list summarising the lessons I’ve learned from JBS so that anybody could use them but it doesn’t work that way. Remember how I said I never bothered with certifications and such like? It’s because there really is no substitute for experience. There’s no substitute for learning by screwing things up, figuring out where you went wrong and ensuring you try to do better next time. No substitute for seeing how much pain and frustration decisions you’ve made have caused normal people (and lots of them), then figuring out how to win them back, turn it around and make the software better. No flowchart you can build that determines when you implement a feature, or build something else that indirectly but more usefully solves a problem, or even when to remove a feature entirely because it’s the “right” thing to do, or when to completely change direction and try something completely different.

You have to learn by doing, and the best lessons are those born from failing, trying again and ultimately succeeding. Leave your ego at the door and learn lessons from everything you get wrong (pobody’s nerfect).

From doing this again and again and again I’m now much better at making judgment calls. Knowing what questions to ask to find out if a software release is going to be late before it actually is and what to do about it. Knowing when to push a release vs drop features. Recognising that instead of trawling through a bug / feature list and implementing them one at a time, when to take a step back and see if there’s something completely different you can do that renders chunks of those issues obsolete. When to look at the big picture and when to focus on the tiny details. I don’t always get it right, and frankly if I ever thought I did then I’d know I was deluding myself.

And if you write software for a living and work in the 99% of companies that are stuck in the dark ages of software development, just do what I did. Find something interesting and build it on your own time, even if it’s as trivial as a desktop wallpaper switcher. It taught me an incredible amount, and the funny thing is when you build something you’re passionate about, you magically seem to find extra time and energy to work on it.

Finally, the one piece of advice I would give is to use a tool like FogBugz – the best defect tracking / project management / source control / customer support system I’ve used. Without FogBugz I’d have been completely lost at sea both working on JBS and professionally. It’s the perfect example of what I aspire to build – software that is so good you don’t even think about using it – it just works.

And to think, JBS was all kicked off by my friend putting monkey pictures on my desktop when I left my machine unattended. Thanks Ben!