If you’re reading this then there’s a good chance you’re a user of ‘Press Play and Go’. Thank you. I’m always touched – and a bit surprised – when people use my software.

This series of posts will explain the development process used and the rationale behind certain decision which affects how the app works (and sometimes fails). It will also touch on various business issues. I’ll try to keep them relatively short and hopefully do about one per week.

It all started back in 2010 – when desktops ruled the Earth – and I wanted to learn how to write iOS applications. So I picked the only idea I had involving my other great love – doing Les Mills classes – and embarked on the best way to learn something – which is by doing it. After a while I had a working application which I released for free as I simply wanted feedback (and, being brutally honest, I wasn’t confident in myself that it was a decent product). But it got a few downloads and the majority of the response was encouraging even when they were mentioning the (valid) faults.

So I added a few more features over the years while starting to realise that although it was now working well (albeit imperfectly at times) I’d made mistakes in the design in terms of architecture and data storage. This was because of inexperience where I’d implemented something that worked rather than being aware there were other options that were better approaches. It’s sort of like pouring the foundations of a house and then realising later on you should have done it a different way: you can still add the new extension but you need to add a lot more support to the outside since the foundations aren’t as strong as they should have been.

This is an issue which affects just about every app and computer system in existence. Decisions made early have long-term consequences and if you aren’t aware of them it can lead to problems. Much in the same way that if you don’t learn proper technique doing squats using light weights then it can cause problems with the back when you increase those weights.

This isn’t to say the app is inherently unstable; it’s just that I’m more aware than most of the flaws in it because I see the code on a regular basis. And only by critiquing it can it be made better.

More recent users may be wondering why they had to pay for the app now if it used to be free. Well it takes a while to collate the song data (about 15 hours a month – I’ll go into that in a future post) and I realised that was really starting to dig in to my spare time. So I put a price on to see if I could get compensated a little for it. It certainly doesn’t mean I’m going to be able to afford a Ferarri in the next few centuries but every little helps.