How Not to Build Phone Apps: A Post-Mortem

The lessons learned from an Android app development side-project

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.


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.

How Not to Build Phone Apps: The Story of Twelve Gauge Software

This is the story all about how, we failed to become world famous app developers right now

I was going to drip-feed this article out in sections, but ultimately decided that it works better in one long go. Before we begin, please note:

  1. The word “Spinning” and its ilk, when referencing static exercise bike workouts, are somehow registered trademarks of Mad Dogg Athletics, Inc.
  2. The memories of the best of us fade with the passage of time, so despite my efforts to recall and plot the precise timeline of events that this article describes there may be one or two small discrepancies in the exact dating.

I am concerned that “Survivor Bias” shapes far too much of what we see and hear in the world of careers and business. I enjoy few things more than reading a good story of failure – something that gives me a good shot of context, something that puts everyone else’s apparent glory into perspective. We all love an underdog, but I have a greater feeling of warmth towards people who were the plucky underdog who failed to achieve greatness, but are happy to celebrate their mistakes. It takes more grit and character to regale people with failure than it does to lecture people on success, and I wish there were more articles out there from people in The Failure Club. “We need to be the change we wish to see in the world,” so where better to start this quiet revolution with one of my own stories of failure. Initially, when first plotting my write-up for this article, I was going to introduce it with a massively sarcastic glimpse of an imaginary end – a beguiling description of a life of success and its trappings, before going on to detail how this came to pass, unfolding an adventure of mobile phone app development, friendships pushed to their breaking point, of failure, and of the eventual hard-won victory – which there wasn’t.

Then I thought – fuck it, why bother. Just tell the damn story. It’s a Hero’s Journey, just without any heroes. There’ll be no victory at the end, but it was still one hell of a journey. This is the story of Twelve Gauge Software.

The tale begins in the summer of 2010, when one day, out-of-the-blue, my friend Dean asked if I “fancied giving this Android app development thing a go?” Both of us were in full time jobs, so any undertaking would be a pure side-project, mainly for the fun and camaraderie, with any profit being a pleasant (but necessary) bonus. At the time Dean worked for a profligate quango (for the benefit of those outside of the UK this is a Quasi-Autonomous Non-Governmental Organisation), and in their spendthrift wisdom they had chosen to bestow upon him an HTC Desire smartphone, for no discernable reason, and it was the acquisition of this device that sparked Dean’s desire to develop something for Android. Upon seeing the phone I too was instantly captivated, and I eagerly agreed to his proposal. The pair of us were completely clueless about Android development, so in the days that followed we set about a-Googling to amass some quick knowledge, and concluded that native Android apps were developed using Java. Who better to rope into this endeavour than our friend Danno – an actual Java developer.

Danno went away and spent a couple of weeks investigating online manuals and forums, acquainting himself with the barebone basics of how to get an Android app up-and-running. Dean and I were confident he’d be able to make sense of what to us was arcane gibberish, as Danno has always been able to muster an Asperger’s poster-boy level of concentration, thus was more than equipped to cope with the fucking obtuse and vague Android documentation. When he reported back to us he was immensely positive, saying that it should be within his capabilities as it’s; “…all about attaching event listeners and…” I forget the rest, as I zoned-out at the phrase “attaching event listeners” as my own comprehension faltered, but the overall timbre of his voice was confident and I knew he understood the words that he himself was saying; that’s good enough for me.

A few weeks later we met up at mine for a brainstorming session: What should our first app be? We paced about my living room, scribbled drawings, and argued about the merits of various suggested avenues. Eventually, out of nothing, I came up with the quirky notion that it would be useful to be able to launch specific apps and actions based on gestures made with the phone – wouldn’t it be great if a certain flick of the wrist and a shake could trigger a false ringtone to allow me to get out of awkward conversations with people who were devouring too much of my time? Perhaps make a phone call based purely on a specific hand fling: speed-dial on steroids? At the time gesture mapping apps had yet to be done to death, and the couple of apps that did something similar to this were frankly appalling. So that was it, decision made; our first app would be a gesture-based app launcher, project codename “Dudley Manlove” (later to be officially retitled “Blindfire”).

That session turned out to be the easy bit, for it was all uphill from then onwards. In Android’s formative days gyroscope support (at both hardware and API levels) was near non-existent, so we spent week-upon-week-upon-week-upon-week wrestling with various ways to map device orientation coordinates. Nothing seemed consistent, so at each weekly dev night we seemed to return to the start, unable to figure out what the hell the numbers we were logging from the phone actually meant. My interpretations of the values would work one week but then fall apart the next, my whiteboard became a mess of rough graphs and number grids, crossings-out and childish sketches of boxes tilting at various angles.

It turned out that we’d been wasting our time; the numbers meant nothing. I wasn’t understating things before; there really was zero support for gyroscope usage in those days, and if we’d studied the Android docs more thoroughly we’d have realised this sooner. Whilst the API promised certain meanings from each of the gyroscope coordinates there were further appendices, stating that these API function signatures were little more than stubs, mere placeholders to be fleshed-out in later Android versions once the baseline level of hardware had risen. With our every attempt to wring something useful out of Android foundering we were beginning to get a little pissed off. Had it not been for the surfacing of a second app idea we might still be fighting the gyroscope to this day.

In September 2010 a work colleague of Dean approached him with an idea for an app. He proposed a simple app that would present the user with exercise routines to imitate spinning classes; static exercise bike workouts at various cadences and peddling speeds, done on a special type of exercise bike specifically designed to support this type of workout. Typically an instructor should lead these sessions, issuing orders and encouragement to a room of accompanying participants, sweating and panting as they struggle to keep up with the level set by this gymnasium obergruppenführer. Dean’s work colleague was coming to the end of a gruelling turn-your-life-around regime, where he’d lost a quite frankly jaw-dropping 16 stone in six months. This was thanks to a carefully restricted diet and spinning classes.

The app would essentially fulfil the role of a personal trainer; the user would mount their phone on the handlebars of the bike and the app would give them visual and audio cues to follow. Our market research showed it to be a promising venture; high demand and low supply – no one had really gotten into this particular app niche yet, but fitness apps as a whole showed solid popularity. The feasibility of building such an app also seemed realistic; a rotating wheel, a label indicating cadence level, a countdown timer, a label saying “stand up” or “sit down” to indicate whether the user should be in or out of the saddle – it all sounded pretty doable.

Project Dudley Manlove was shelved, never getting beyond its proto-R&D feasibility stage, an idea we hoped to return to when the technology caught up with our aspirations – we had wanted to make an app that could turn a phone into a magic wand but had been thwarted, so we admitted defeat and moved onto the new project: Virtual Spinning Instructor, project codename: …I can’t remember…it was another actor from Plan 9 From Outer Space…Tor Johnson, that was it.

With a reasonably-granular design quickly in place we jumped into action in November 2010, but our initial progress was slow, with Danno still prodding and probing his way round the peculiarities of Android’s implementation of Java, and Dean and I finding it tricky to produce a clean UI for the app without it looking like a 5 year old had knocked it together (we eventually discovered that DroidDraw wasn’t the answer). With one group dev night a week for in-person discussion, and initially using the soon-to-be-discontinued Google Wave as an idea collation and chat forum, we each chugged away in our spare time. (NB. I really liked Google Wave, I wish they’d stuck with it a bit longer.)

Weeks passed, and we had several things in place. We had a main screen, with animated rotating cadence wheel, and we were busy coding the logic for the workout routines that would inject life into that screen. There was still a hell of a long way to go, not least because this was the first production code we’d written for Android, and as such we knew that there’d be bits we’d have to tear apart and rebuild to improve performance. Initially we were aiming for something that worked and hung together as a cohesive whole, and we hoped to have version one ready in about six months.

It was lunchtime, Monday 10th January 2011. Dean was contentedly sat at his desk, working on whatever stuff he was doing back then, when he received an email from his work colleague (the formerly-fat one who had come up with the app idea); for some ungodly reason he’d contacted BBC East Midlands local news about his tremendous weight loss exploits, and that he’d been using a new Android spinning app to help him; our app – our as-yet unfinished and nowhere near release-worthy app. The BBC insisted that they send a camera crew to interview him and see the app tomorrow, and he foolishly agreed. Dean emailed me in a state of utter panic: we needed to get a semi-working version of the app ready for the next day, so that they could show it on the news. Fiddlesticks.

That evening Dean and Danno came to mine for a frantic coding session. Despite intense fatigue, by 11.00 p.m. Danno had mustered something that built successfully and was working…well, semi-working: it would crash after about thirty seconds as the workout routine transitioned between stages, but it was good enough for the mere handful of seconds that it would appear in a tiny news segment. Danno was exhausted and went home to binge sleep, so it was now Dean’s and my shift at the keyboard. We stayed at it till midnight, trying numerous ways to make the build installable in dev mode on Dean’s phone (up to this stage we’d still only ever had one Android phone to work with: Dean’s HTC Desire). Eventually we got the APK to install, and we emailed it straight to Dean’s work colleague. At half past midnight he phoned back to confirm that it also worked on his phone, so having done all we could Dean went home and I tried to get some sleep.

As promised, the next day the BBC visited Dean’s formerly-fat work colleague to interview him about his colossal weight shedding. The video segment would later find its way onto the BBC news website, but I couldn’t wait that long to sate my curiosity, so I arranged for several friends and family members to record all local news segments for the next few days to ensure I got it snagged, whenever the BBC deigned to broadcast it.

Upon watching the segment two particular practices within BBC broadcast journalism were apparent. For a start they obviously don’t think that the general public will understand technology-sector job titles beyond the most vague and generic of descriptions, as they grossly misrepresented Dean’s work colleague as an “IT Consultant”, when in fact he was a sysadmin. Secondly, perhaps to their credit, they chose to cut the many attempts he made at shoehorning the name of the app and our development team into the interview, eventually the creation of the software being simplified to a mere “I’ve designed an app”. Alas we would remain creditless.

Proudly showing the news segment to my parents, saying, “That thing there on his phone, the thing with the wheel on it: we made that,” didn’t quite get the impressed response I was hoping for. My father ignored the appearance of our app, his main comment being: “That fella’s got a good pair of dibs and dabs on him.” (Translation: “That man has substantial ears,” a pair of which Dean’s work colleague indeed possessed.)

With the app still nowhere near ready for release the local news segment produced only problems for us, notwithstanding the aneurism-inducing late night rush-job to get a demo working for it. We started receiving emails from people who had seen the news coverage and were wondering where to find the app. The polite answer I gave was: “We’re hoping to have it ready soon, we’re just finessing one or two things,” but the real answer should have been: “I honestly haven’t got a frigging clue – we’re not even nearly ready. I don’t know Java, and I’m still not entirely sure what my purpose on this team is, other than making tea and eating Dean’s Maltesers. Oh and replying to these emails – yea, that’s my thing.”

Slow progress became even slower when, in February 2011, we welcomed the birth of Dean’s first child, further knocking our collective’s productivity. Dean is the first to admit that, whilst enjoying parenthood, he’s never found it to be a walk in the park, and his attendance at weekly dev nights evaporated. Behind the scenes Dean continued to work on the app visuals, which he could easily email over to us (being just XML text files), whilst Danno and I plodded on with the main app logic.

The inquisitive emails from eager prospective users went on for months, but a confirmable release date was still miles off, so I continued to fend off this curiosity as best I could – a unique challenge of trying to quell the fire of interest without putting it out, the old simultaneous dampen-yet-stoke. Our morale peaked and troughed on an almost daily cycle, as the small wins we achieved with breakthroughs in the code got eroded by the catastrophically vague crashbugs that would appear out of nowhere. We got used to Android fighting us all the way, but not once did we ever consider abandoning the project.

In retrospect our workflow could have used a little streamlining. A perfect example of the absurdity was how each of us worked remotely with the codebase. Danno’s day job meant he had tremendous experience with Eclipse, it having been his main IDE for many years, and he hoped both Dean and I would be comfortable working with it too, and to use it to push our changes to the remote BitBucket repository. Alas both Dean and I were (and still are) absolutely petrified of Eclipse, both being more used to Visual Studio’s comparative terseness. The pair of us did most of our tweaks in Notepad++ and saved our code as text files, to manually integrate them when Danno was around to supervise; neither of us wanted the honour of being the first guy to break the build and fuck up Danno’s hard work, because he’d never let us hear the last of it. We were also painfully aware that our Java knowledge extended no further than being familiar with fundamental C-style syntax, so anything beyond typical logic structures required Danno’s assistance. Plus, as Danno refactored everything we did anyway, we knew our unsupervised pushes to the codebase was an infiltration – a stealthy insertion of sub-standard code. We didn’t want to distract Danno; he was shouldering 90% of the development burden, with Dean making a vain attempt to learn some of Java’s quirks and me just trying to wing-it. Despite our disjointed work practices, as summer turned to autumn and autumn to winter in 2011, we were satisfied that we almost had a version one ready to go, after over a year of development.

For some baffling reason we slated the release day for Christmas Eve 2011. Dean wanted to time the release to coincide with New Year, to ride the inevitable demand wave of the populous’s predictable resolution to exercise more and get fit. Unfortunately the first release build didn’t go quite right, so after a quick phone conversation Danno whipped up a revised build and emailed it over to me (managing the publishing and interacting with the Google Android developers’ portal being one of my disparate responsibilities). Thus the actual release day slipped to Christmas Day 2011. We felt good…well, Dean and Danno did – I was in the process of being dumped by the lady I was dating, so I felt shit, but the app being released into the wild brought a little relief.

Indoor Cycling Coach, nee Virtual Spinning Instructor

If only that could be the ending to the story, but we know stories like this never end neatly. Despite zero marketing and little product awareness, within 24 hours we had downloads, purely from people searching on the Google app store, and accompanying these downloads were reviews; many good, many bad. Users started to email us asking for new features, reporting bugfixes and requesting specific device support, and our product backlog started to swell once more. The respite hadn’t lasted long enough; the pressure was back on and we needed to return to the coalface straight away, otherwise the negative reviews would start to pile up and drown us; we couldn’t afford to lose momentum.

So the slog began again in earnest, with Dean working on a revamp of the visuals and some tutorial screens, whilst Danno and I continued to devise and deploy bugfixes and new features. We made it through to April 2012 without further incident, but then we hit a big problem. On the 1st of May we received an email from a US company accusing of us of infringing their trademark on the word “spinning”, when used in the context of indoor exercise bike workouts:

I’m sending this email to you regarding the app your company has developed called “Virtual Spinning Instructor”.

Our company, Mad Dogg Athletics, Inc. are the creators of Spinning related to indoor cycling ( It is imperative that you contact me immediately regarding the misuse of our Spinning trademark related to the above Android application. I can be reached at REDACTED during the hours of 9:00am and 6:00pm PST (California) or on my cell phone between 6:00pm and 11:00pm – REDACTED. You can also send me an email – REDACTED.

Again, it is imperative that you contact me immediately. Regards, Rhona Attwater, Executive to John Baudhuin CEO, Mad Dogg Athletics, Inc.

Our app, Virtual Spinning Instructor, clearly breached a trademark which Mad Dogg Athletics had registered in territories spanning the globe, a trademark that of course none of us even knew existed – or even could exist; we’d always thought that spinning was the generic name of a type of workout, akin to saying “I’m going for a run”. If Mad Dogg Athletics knew about the number of gyms in the UK and Europe called “The Spinning Gym”, “The Spin Centre”, “Spinning Fitness” or names of similar ilk then they’d have a litigation meltdown.

The next day I headed round Danno’s for our dev session, and we got Dean on the phone to discuss our predicament. We had no choice; we had to change the name, and we needed a new one fast. We threw various words, phrases and idioms back and forth, and I drove home with a head foggy with synonyms that might describe the sort of exercise encompassed by “spinning”, but didn’t use that particular word in any way.

Back home, now nearly 10.00 p.m., I fired up my laptop to respond to Rhona at Mad Dogg Athletics:

Hi Rhona,

We’re UK based, so phoning you would have been a bit of a nightmare, so we’ll have to continue this correspondence via email if that’s ok.

I have to admit we had no idea the word “Spinning” in this context was considered as a trademark, it appears we have accidentally trodden on your toes somewhat. It looks like we have no alternative but to rename our app. Give us two weeks and we’ll have it rebranded.

Twelve Gauge Software.

Ten minutes later, just as I was about to shutdown, I received a reply:

Actually Drew, shoot me your number and I’ll call you right now.

Following a little bit of trouble communicating my landline number to her, replete with all the necessary prefixes for international dialling, I received her phone call and for fifteen minutes I talked to Rhona, over in California. She was very polite and friendly, though I’m not sure she found the clash of her 100% pure American accent with my thoroughly Nottingham-UK brogue quite as humorous as I did.

It took us less than twenty-four hours to come up with a new name, and with a quick re-jig of the app and publishing profile Virtual Spinning Instructor vanished, to be immediately re-released as Indoor Cycling Coach. In the following weeks we received a few emails from new users, saying that they’d had trouble discovering the app, and suggesting that we “rename it to something with spinning in the title?” I would reply to these people with a brief summary of our problem with use of the word “spinning”, and that we were now using a name with as accurate a description as we were permitted to conjure.

During this period the other incident of note was Danno’s successful attempt to port the app to the stillborn BlackBerry app store. Around this time RIM made a so-late-it’s-not-even-fashionable entrance to the neo-smartphone and tablet market, and tried to lure developers to their platform with the promise of a free BlackBerry PlayBook for anyone who jumped onto their belated bandwagon and released an app. Danno could not resist the lure of a freebie, and he turned out to be one of the few developers on the planet who could actually make sense of the broken tools RIM had produced to port Android apps to the BlackBerry OS. With the app ported, accepted and available on RIM’s app store Danno began to wait for his free new PlayBook to arrive. To this day he’s still waiting, which is probably for the best.

With the bugfixes and tweaks having made the app reliable on 99% of devices we began to look to the future. Our current release was the “LT” or “Lite” version; free to download but bearing a ghastly advert banner at the bottom of each screen, coughing up all manner of unusual marketing materials to our audience’s eyes. From day one the profit model was a square peg in a round hole, as no one with a grain of common sense would want to click on an advert whilst they were sweating away on an exercise bike in the midst of a workout session. Having said this, we had had to implement a pause and resume function within the lite version, not because people were requesting the ability to pause the workout for a few seconds (which I think is a reasonable use-case), but because a few people wanted the ability to pause their workout and return to it later – as in later that day. Whilst these people were clearly fucking morons who didn’t have a clue how a fitness regime should work we added the facility anyway, aware of the potential for negative reviews if we didn’t. Aside from utilitarian functions such as this, we had a list of feature requests and ideas that we had deemed beyond the scope of the lite version, so it seemed the perfect time to begin work on “Premium”.

From our icebox of features we plucked out those that we knew to be in demand and were also simple to implement, such as more exercise routines, Facebook integration, calorie and distance counting, and of course a performance leap with the expulsion of that fucking clumsy advert panel. Danno created a fork of the lite version’s code, and started work on the social network integrations, whilst Dean continued working on visuals and I produced the circuitous logic required for the many new workout routines.

Alas, the endorphin-induced productivity frenzy on our new project was soon knocked, again by Dean’s pedantically efficient spermatozoa; he announced that he now had twin girls on the way. With the babies due in the autumn of 2012 we didn’t have much time before his attendance would drop even further, beneath a tide of dirty nappies and sleep deprivation.

We plugged away, Dean had his twin girls, we continued to work, another year went by, and we progressed to a stage of being 80% done on the premium version – at which point we became stuck. Unable to find the time to commit to serious testing of the product we couldn’t risk pushing it out to the market; we couldn’t be sure that most of the pieces would hang together, and when people would be paying for the privilege we knew we wouldn’t have the grace of: “it’s only a free app, what do you expect?” I continued to receive emails asking about the possibility of adding certain features to the lite version, and I continued to assure people that a premium version would be here soon enough, replete with all manner of special goodness.

As 2014 came round a new version of Android was released that, for no obvious reason, caused a crashbug in the venerable lite version of Indoor Cycling Coach, and through sheer force of will I mustered the motivation to badger Danno into coming up with a patched version, while I stood over his shoulder cheerleading his efforts. With this small hurdle solved we were back to the problem of What To Do About The Bastard Premium Version.

I probed Dean and Danno’s opinions about the possibility of admitting defeat and wrapping things up. To me our options were threefold:

  1. Make one final concerted push to get the premium version out, a death march of huge, friendship-obliterating proportions.
  2. Mothball Twelve Gauge Software, and leave the LT version on the marketplace to do its own thing, allowing it to slowly slide into obscurity.
  3. Flip our assets (both the lite and semi-finished premium versions) to make a little residual cash out of the endeavour, then mothball Twelve Gauge Software.

Dean couldn’t really surrender any time to finalise the premium version, what with now having three kids and all, so from him it was a vote for option 3. Danno was also fine with this, announcing that if we had the energy to muster option 1 we’d need to get cracking very quickly, as in September he too would be having twin girls. I don’t know what they’re putting in the water in Hucknall, but whatever it is – it fucking works.

With this decided I took a few days to do some research, then signed up for Flippa without properly reading through their marketing spiel, and it was only once I’d finished the registration process that I realised that they don’t deal with the sale of Android apps – only websites and iOS stuff at time of writing. So it was over to Apptopia, the only other app flipping platform of any real repute that I could find. Our listing is up, it’s had a few views, but up to now we’ve had just one offer, for $500.00, which we’ve politely declined. The world of app flipping is still in its infancy, and people don’t want fixer-uppers like ours, they want template toolkits to build clones of Flappy Bird, for which they’ll pay handsomely.

And that brings us to the present. Have we learnt anything from all of this? Yes, but I won’t go into that now. I’ll be elucidating my thoughts about the valuable lessons in a later article, but what I will say is that all of this hasn’t knocked my hunger to produce a truly spectacular app; I’m working on one right now. The difference this time is that I’m on my own, without the interlinked dependencies and camaraderie of a team, but at least there’s no threat of sudden onset twins to dampen my spirits.

An Email I Sent 10 Years Ago

Time to clear out my accumulation of old emails, but first a walk down memory lane

As my digital spring-cleaning drags on deep into summer I have progressed from sorting through my web browser bookmarks to clearing out my archive of emails. It would go without saying that I’d saved a lot of old crap from people to whom I haven’t talked in years, but one area of interest I almost overlooked was my own old sent items. I now have a nice Thunderbird rule established that will delete the stuff I send after 28 days, but before I put this live I had time to have a read through my old correspondence, and I spent many a long moment staring into the middle-distance, silently reminiscing about times gone by.

I sent the following little beauty to a few friends back in September 2004. We’d graduated from university a couple of months before and, freshly-qualified, we were all on the hunt for jobs to start our careers in IT. Up to the point I sent this email I’d had little success on finding a job, not for the want of trying, and I had been feeling rather sorry for myself. Here’s the email I sent, telling my friends the story of the week that, ultimately, resulted in me landing my first job in IT.

SUBJECT: One Week: Success, Failure and The One-Armed Man

Gather round, and hear a tale of mystery, terror, happiness, stress and panic. It’s a long story, so go take a wee now, because I won’t be pausing for anyone. Welcome to the story of my week.

On Monday I went to an interview for a helpdesk job at REDACTED, an EPOS systems provider just outside of Nottingham. It was a shit interview, which started as it meant to go on; the guy insulted me twice and said that programming was a terrible career to be in; unrewarding financially and completely boring. These words may have sounded better if he wasn’t interviewing me for a poxy underpaid helpdesk job, which we all know is much more creatively rewarding than, oh, say a career in programming. I left there knowing that, even if they offered me the job, I wouldn’t want to work there because I would end up punching the guy who interviewed me (who was actually the MD, and a complete twat) repeatedly in the face. The interview lasted thirty minutes – which seemed brief – but as he really didn’t know how to conduct an interview in hindsight half an hour was probably too long. I wish I had had the balls to verbally insult him on my way out.

In total I was scheduled to have three interviews this week, but on Tuesday morning I received a call from a man at REDACTED (an IT support business with two offices, the second just having been established in Nottingham, the first down in Surrey) who asked if I’d like to come for an interview the next day (Wednesday). I agreed, and phoned him back later to arrange a time and confirm the address. He had never actually been to this new office himself (he was in his car on the way to said office during our phone calls, on the drive up from Surrey), so he had to phone back the next day when he’d figured out where the place was.

Tuesday afternoon was a much better interview, where I jetted off to sunny Sutton-in-Ashfield (a mere ten minutes from my house, less if I speed) for an interview with REDACTED, a tin can manufacturer. Before anything else I was given a personality test, which, presumably, was to check whether I had a personality or not. I quickly completed this and was then interviewed by a woman from HR who was very friendly. She then swapped with another woman who turned out to be the IT Manager, who interviewed me on a more technical level but we still managed to have a bit of a laugh. I went home afterwards feeling good about the whole thing, a definite improvement on the day before.

Wednesday’s interview at REDACTED was at 2.00 p.m. Unfortunately Beeston is a forty-five minute drive at a good time, and can take an hour and a half in bad traffic from where I live. Fortunately my dad has been acting as a great taxi service for several interviews, because (a) he knows Nottingham better than I do, and (b) he’s retired so has nothing better to do than ferry me back and forth – it keeps him busy and stops him bothering my mum.

Anyway, I arrived and entered the converted house on Beeston’s main street that they had just moved into – as we walked through to an office off from the main room they apologised for the fact that it looked like the Pamplona bull run had just torn through. Two men, both called Andy, interviewed me for twenty minutes. Well, Andy 1 interviewed, Andy 2 sat there with his hairy hands, just listening, and then offered two questions at the end. They said I had the core skills but lacked experience, but there may be a position come up in three months or so, and they’ll keep me posted. I left a little perplexed at how this interview took twenty-five minutes and the previous day’s had taken two hours.

Thursday was a free day, so I watched Finding Nemo. Never seen it before. Not bad. I liked the albatross and the sea gulls.

Friday was rather action packed. Got to REDACTED (sited at a technology park near the University of Nottingham) for 10.30 a.m. It was a group recruitment day, so there was me and five other applicants round a big board room table, and till 12.30 p.m. we were given a talk by the CEO about what the company did (building mission critical messaging and directory technology), accompanied by a woman from HR (unmarried, 40s, kept looking at me; I’m in. Either that or I’d got something stuck to my face). Their aim was to hire two from the six of us.

We were then given a personality test; simply choose the most and least likely attributes to describe ourselves from a variety of words. After this me and the boys had a little chat while we waited for the three department heads from Programming, Testing and Support to come and give us an overview of their respective departments. I’d gladly accepted a cup of tea earlier when offered by the HR lady, and I reckon it was the quinine on an empty stomach that triggered an agonising headache. My fidgeting caught a few glances from the programming and support heads, the latter of which was sitting right next to me, as I sat frowning intensely in an attempt to restrict the pain from coursing through my brow.

After this we were given lunch, and many plates of sandwiches, onion bhajis, cake, fruit and those spicy meat things on sticks were brought out. Whilst waiting for the queue to thin (I wasn’t hungry, but desperately wanted a glass of water) I went to the toilet and had the longest piss I’ve ever had. Around a dozen members of staff had been brought in to mingle with us, and I talked to about six of these guys which was informative and friendly, getting a few laughs along the way because I’m a funny guy (apparently). During this chitchat I noticed that one of my fellow interviewees had only one arm, the other missing at the elbow. After the staff left and the food cleared away we were then given a tour of the offices.

Back at the board room we were issued with programming tests; multiple-choice questions for C++ and Java, and a “Do a high level design of this scenario” paper. They didn’t expect people to know both C++ and Java, but you could do both if you wanted to. I did both, despite my Java knowledge being pretty non-existent. After these tests, and with the silence of the room threatening to become oppressive, I asked the one armed guy if he found it difficult to type, to which he warmly replied that it wasn’t really a problem because he’d been born with only one arm, so it was all he knew. I then asked him if being born with only his left arm made his brain wire him up as left-handed by default. He replied that he thought he might actually be right-handed because his writing always felt un-neat. I reassured him that despite always using my correct one my handwriting was still frigging atrocious.

We were then told by the HR lady that each of us would have two fifteen minute interviews; one technical and one “personal”. They would operate these with two interviewees at a time and then swap them over, so the two going last would have to wait an hour for their interviews. I was one of the middle two to go, so in the mean time I regaled the remaining group with tales of my many interviews since graduation, seeing as this was my 11th and they’d all only had one or two.

The technical interview went quite well; I’d scored 60% on the C++ paper but bombed on the Java, which I wasn’t surprised at because I was blagging it. The personal interview was always going to be the easier of the two, and that went fine. With these interviews done I was free to go, so after five and a quarter hours I left at 3.45 p.m.

Having switched my phone back on I discovered two voicemails, one from the factory in Sutton-in-Ashfield and the other from the support company in Beeston. I immediately telephoned the factory and the HR lady invited me back for a second interview next Friday. When I got home I phoned the Beeston place back, and after my rather busy week this phone call was the shit-flavoured icing on the cake. The bloke on the phone wasn’t one of the two Andy’s, so he gave me a quick ten minute phone interview to get up to speed on me. I suspected he was about to invite me back for a second interview next week, even though they’d implied before I wasn’t experienced enough for the job, but instead he offered me a position right there and then, collectively having been interviewed for just thirty-five minutes. I asked what the package was, and here came the sting: a £10,500 salary during the first three months, rising to £11,500 after that, and 20 days holiday. I’d also be expected to use my own car to get to and from the client sites that I might be working at.

I stifled a snort of derisive laughter, then lied and said that I’d been offered £17,000 by someone else (the deal from the messaging technology company is £17,000, though I won’t know whether I’ve been offered that until Monday or Tuesday next week). He was a bit stunned, but I had to go for shock tactics to bring him into the real world, as it was clear he didn’t have a clue what a reasonable offer consisted of, and he sure as hell was never going to get anyone for that wage. I can earn more by stacking shelves or scrubbing toilets.

And there you have it. My week.

(As a quick conclusion; to my massive surprise I was ultimately offered jobs from all of the businesses that interviewed me that week, and I took the one at the factory.)