How Not to Build Phone Apps: A Post-Mortem

It was an unintended consequence, but publishing my previous article on the trials and tribulations of developing mobile phone apps has curiously resulted in a spate of job offers. It turns out that a little honest contrition over a failed endeavour is brilliant at establishing credibility on a subject.

The previous article was the backstory, and this follow-up is the post-mortem; what did we learn? What could we have done differently, and what strategies and tactics can we take away from our disorganised attempts at phone app development?

Capitalise: Quickly

I hate having to recommend that people must work fast to succeed. Whilst I have a reputation for blitzing rapidly through pieces of work I do like to take my time over certain key tasks, unafraid of allowing some mulling time to let my subconscious do its background thing and solve some problems while I daydream. Unfortunately, in our little skeleton crew at Twelve Gauge Software, time was always of the essence.

In the previous article I labelled our endeavours a failure, and this was a misnomer; it was a mistake for me to describe things in that manner. We’ve had around 30,000 installs of Indoor Cycling Coach, of which a third are active; a retention yield that is massively above the mean average (the typical yield is more like 10%). The failure was not that we built something that didn’t work and no one liked – we succeeded on both those counts. Our main snag was that we failed to capitalise on our initial success, with hindsight we should have had what I’ll call a “roll on” plan, that would have come into play after our “roll out” of version 1 had been completed. Everything we ever did was pure improvisation, and because of this we never anticipated the popularity of Indoor Cycling Coach, and never considered planning further ahead than the initial version that we were in the midst of building. We’d have been happy to grab a few hundred active users, but when you reach 10,000 your userbase begins to have some weight, and this can work both for and against you. If we’d planned for the eventuality of actually being popular we could have put advance work into the Premium version (that we still haven’t gotten round to releasing), but instead we stagnated, floundered and flapped about, bouncing from one crisis to the next. For example, if I’d thought about the possibility of us releasing a Premium version then I could have started algorithm design on the new workout routines whilst Danno and Dean were finishing off the Lite version. The effort put into this preliminary work wouldn’t have paid off until maybe six to nine months later, but when the time came around to actually begin proper development work on V2 we’d have been ahead of the game, and the burden much more manageable. I didn’t make the best use of my downtime.

Hype: Synchronise it

Pre-release publicity is great, especially when it’s free like ours was – but unfortunately our BBC media coverage could hardly be called “pre-release” as it came almost twelve months prior to the launch of the product. If you’ve read the previous article then you’ll know that the timing of the BBC exposure wasn’t our own fault, but regardless of this I didn’t manage the resulting interest from the TV coverage with any great panache. Whilst I did get to add many emails to our mailing list I don’t like to think about how many people slipped through the cracks: how many made a cursory search for the app, found nothing, then didn’t go to the lengths of finding out who the developers were and contacting us directly? It’s a safe guess that the people who did get in touch were the minority.

The solution is to have a proper mailing list setup and ready to rock, long before you do anything else. Having the facility for users to sign-up to a mailing list is vital, and I dropped the ball on this. We didn’t have a mailing list until the very first email arrived from an interested prospect, wanting to know where the app was. Even after this we didn’t actually have a “proper” mailing list, as for some unfathomable reason it never occurred to me to create a quick MailChimp account to house the emails we were collecting; instead I manually housed them in Excel. Beyond the storage convenience of using a managed service we also missed out on a more useful and obvious feature; the ability to insert an automated user sign-up form in your website. I only added emails to my list when people contacted and asked to be kept in the loop, but a simple subscription form (like the one I’ve had for ages on my own fucking website) would have built our subscriber list without the hassle. Obvious: yes – but in the heat of the moment it never occurred to us, our heads cluttered with the burden of product development: the thirty or so names on our mailing list hardly seemed worth worrying about.

Anticipating future interest – and thus setting up a mailing list subscription page on our website in advance before we hit deep water – would have saved so much time and stress later, and we could have fired off regular emails to our growing list of subscribers, to keep the fire of interest fed over our lengthy run-up to release. I fear interest in the app peaked way too soon, and thus a shepherded mailing list would have allowed us to regulate our fans’ curiosity, to discharge it at the correct moment. A sense of timing is very useful.

Maintaining momentum: Fits and starts

Progress atrophy is one of a skeleton crew’s biggest threats. If your DBA goes on holiday for a month and she’s the only one capable of doing anything with the database then you can bet your arse that as soon as their plane takes off you’ll realise that all your blocking tasks are database related. All you can do is twiddle your thumbs and wait till they get back. Whilst this specific example didn’t happen with us we certainly had moments where we needed a teammate to complete his bits of work before we could start ours.

Even a tiny amount of knowledge is fine here, as all you need to do is keep moving forward. A slow trudge is better than nothing, and just keeping the momentum going at a miniscule level is acceptable. Blocking tasks shouldn’t have to be left unattended; they should be chipped away at. Ignore those who say that “a little bit of knowledge is a dangerous thing”; you should have backups, you should have source control, and (back to the example) the DBA can polish or reengineer the shit you produce when she gets back – you can’t irreparably break anything, so why not get stuck in? The aim is to remove the blockages any way you can, or at least chip off enough of them to permit progress for the rest of the team, to keep productivity above zero. This leads me to the next point.

Team Responsibilities: Jacks-of-all-trades versus specialists

Being ignorant of alternatives (though when we first started there weren’t many) we opted for native Java-centric Android development, and only one of the three of us was a Java programmer. We were hobbled from the get-go; locking ourselves into a narrow skill ownership, direct responsibility-based structure that was clearly unsuitable for a tiny startup-esque enterprise. In a three person team you can’t afford to specialise.

I’m not saying that everyone shouldn’t have their own primary role – the job that they perform most often because they are the best at it – but each person should have enough knowledge to be able to do the tasks of everyone else if required, even though this might only be a merely functional level of ability. In hindsight, when the tools became available, we would have been better rebuilding Indoor Cycling Coach from scratch as a hybrid app, as all three of us know JavaScript and HTML. Multi-skilling and the ability to job share is paramount: things would have turned out so very differently if we’d had more skill overlap.

Words and pictures: Group communication and idea collation

For communication, remote brainstorming and idea collation, use whatever technology is easiest to implement and use, even if it lacks fancy complex features. The simplest and fastest thing to use will get used, and the all-singing-all-dancing software that does a million other things will get ignored and neglected.

Don’t waste your time on it. Enforcing a technology on a team is difficult, regardless of the team’s size. If you find that a big “Reply All” group email is working well for you then that’s fine: go with that. Email will always have a place in this world: ignore the naysayers and cult-of-the-newists who build products that tout that they are a “replacement for email” or are sounding the death knell that “email is dead”. SaaS product startups need to cotton onto the fact that email doesn’t need slaying or replacing, it needs powering-up, to be used in new and interesting ways.

I digress. At Twelve Gauge Software we started off using Google Wave for discussion and idea collation, and I was a massive fan of it because it just frigging worked. Typing text in a box and clicking a button, and then it was up there, straight away, no bluff or bluster. At its core Google Wave was little more than a forum CMS with added beef and poncey functionality, but those extras were simple and seamless and didn’t require additional effort from the user. Clearly my love of Google Wave put me in a minority, as it was unceremoniously shut down, and since then I’m yet to find a web-based group brainstorming tool that I like as much. Until I do I will continue to use simple email and chat channels as my comms system of choice for small teams.

The Long Haul: Know what you’re getting into

…and letting yourself in for – the time commitment will be several multiples more than whatever you’re planning for. If we’d have known just how much effort would have to be put into Indoor Cycling Coach would we have started it in the first place? Perhaps not.

The fun and the adventure we had along the way were more important to us than the finished product, but it’s still hard not to be disappointed when there’s no end in sight. During the day-to-day grind (or evening-to-evening grind in our case) you don’t consciously clock how many hours you’re putting into something. It’s only when you’re sat at your laptop trying to make sense of the Google Play developers’ portal – on the afternoon of Christmas Day – that you realise things have gone off-track a little. You must accept that there will probably never be a finish line: new ideas for features to implement will spawn, new platforms to reengineer for will be released (for example the tablet market didn’t really exist much when we started), the bugs will keep on coming, and the work just spools out over the horizon to infinity. If you don’t love the product you’re building then you might be better off waiting for a better idea to come along, something that you won’t mind giving up your free time for.

Conclusion

Anticipation is the key. The overarching theme of my observations is that a bit of preparatory work, in advance of jumping into development and coding, will pay-off massively later on when you haven’t got the time or concentration to spare. One of our initial tasks was a brainstorming evening to come up with suitable app ideas, but as soon as we had decided on a feasible idea we should have had a second brainstorming session; to expose our thoughts on the vision for the app, whether we can guarantee to support it in the long term, or whether we’d get it up-and-running and then flip it to someone else to look after. We had no future vision – we were just making stuff up as we went along. Setting yourself up correctly at the start won’t suddenly make everything easy, but it will make everything easier.

Back to Top