Picking My “Going It Alone” Project

ChangesThatStick.com (CTS) seemed a perfect project for my “going it alone” sabbatical year. It felt complex enough to get my teeth into, but also small enough to finish a decent version of it in 6-8 months. It was also something I genuinely wanted to use, as did several friends.

I came up with the idea in June 2012, after spending the first few months of my sabbatical year pursuing development of a new generalised software testing framework, the idea for which I had about 5 years back. I found that the framework, whilst interesting, was going to be way too complex for one person, would take much longer than a year, and probably wouldn’t be commercial once finished. Since I had the idea, a number of open source alternatives have filled the gaps I was attempting to fill. In May, I came to that realisation. And in June, I moved on and looked for a new project. I always said that it was an idea I needed to get out of my system, pursue, and either prove to be worthy or kill. It was the latter.

CTS was born from my use of several “life hacking” / goal tracking / fitness and health iPhone apps. I had been tracking my water consumption for months, using my Withings wi-fi scale to keep track of my weight (the laziest way to track your weight, but a must-have gadget), and yet I couldn’t find software to let me track my gym workout goals in a flexible way, or an app that would allow me to add new goals without purchasing an additional app for each. My goals were fragmented across 6-7 apps, each of which either needed me to launch that app several times a day, or which would nag me via bizarre iOS alerts at the least convenient moment. (Why I want to know how I’m doing with my weight goals whilst I’m in a meeting, I’ll never know!)

Generalised Goals and Targets – The idea behind CTS was to allow general tracking of any goal or target. Users would record activities, some of which would be associated with measurements: body weight, gym reps, volume of water drunk, etc. It would allow some simple stats to be derived from those activities, aggregated over a chosen time period: number of gym workouts per week, most recent weight, lean weight, total volume of water consumed per day, etc. Then, goals could be set on those stats: My weight must remain below 66kg, I must do at least 2 gym workouts per week, I must drink less than 8 units of alcohol per weekend, etc. The goals would allow entry of a schedule, such that they could change gradually over a period of time, allowing users to adhere to a schedule that takes them from where they are now to a future target they aspire to.  This is something that gym trainers tend to do well, but which folks tend to do badly for themselves.

I wanted to tackle the whole issue of measurements in a nice general way. So many life hacking apps get hung up on restrictive units, ways of entering values and ways of displaying values. I believed it should be possible to generalise measurements, define well-known types (volume, length, time, and many more), configure all known units for each, and ways of converting between those units. I also knew it should be possible to allow a lot of flexibility in the way those measurements were entered and displayed. It just felt like something eminently generalisable. The kind of challenge a software engineer loves.

I also knew that certain measurements should be derivable from the values entered. A user entering their body weight and fat % might want to track their lean weight, or their BMI (if they enter their height). A runner may want to know their average speed. I felt that all of these should be available in a general way.

At-A-Glance Visualisation – Coupled with this ability to track and set goals, I wanted to show users how they were doing at-a-glance (you’re busy, right?!). For the current time period (“today” for daily goals, “this week” for weekly goals, etc), I wanted them to see whether they were already on-track and, if not, how far they had to go. The ability to glance at this, across all goals on a single screen, would give users a view of their efforts without the need to open multiple apps. Colour-coding would help (green for on-track, red for off-track). It would also remove the need for intrusive alerts; you check progress whenever you’re free.

demo02 - water

Dive Deeper, When You’re Ready – When users felt ready to delve in, they would be able to drill down and look at recent performance (past few days / weeks / months), and see a nice graph of their performance since they started tracking the goal. I felt that these views should be compelling, and knew that it should be possible to generate graphs with nice axes, readable labels, etc. Another area I felt a software engineer should be able to tackle well, but where so many apps fail miserably.

Users would also be able to alter the goal and its associated targets. Crucially, they would be able to alter the goal schedule for the future, but not revise it for the past. Cheating mustn’t be an option!

demo06 - waterdemo07 - water

Single User Interface across all devices – The app needed to allow rapid entry of activities, via desktop and mobile. Anything more than seconds to enter an activity and it would become a hassle. Longer-term, I knew it might be possible to integrate with third parties and capture activities (distances run, body weight).

This was the point at which I realised I was never going to be able to develop a native mobile app (iOS and Android, plus others), and offer a desktop/tablet version, as a one-man development team. Reality began to bite. Even with several developers, the task of keeping those interfaces in-sync would be daunting. And so, the idea of a single web-based user interface that worked on all devices was born.

This raised the question of how to provide a dynamic interface in a browser, rather than the usual form-filling, page-refreshing, clunky offering. Luckily, as part of my earlier work on the test framework, I had developed my own UI framework (perhaps overkill, some would say, but there were reasons). I’ll write a separate post in a few days on why I did that, and how it worked well for CTS.


First Steps and Timescales – Once I had the idea, and I had solidified how it might work during a July trip to New York (nothing like 8 hours trapped on a flight with a laptop for working on an idea), I decided to get serious about a schedule. I gave myself until September 1st to come up with a demo. Crucially though, I decided the demo must use the real UI framework and as many real components as possible, but with the app logic faked wherever it wouldn’t detract from the demo. Therefore, storage and retrieval of model entities (users, activities, goals, etc) would be faked with demo data, certain visualisations might be primitive, but, other than that, the app should be working as intended.

The demo would also be done in-person on a laptop, removing all deployment issues from the frame. I figured that, if the idea didn’t survive a demo, there was no point in looking at deployment. The same obviously went for issues such as model storage, databases, security, emails / signups and scalability.

(I will cover considerations of profitability, payment model, and whether I thought the app was even commercial in a future post. For now, I’ll focus on the technical aspects only)

Demo and beyond – During September, I showed a laptop demo to a few friends and ex-colleagues. Most liked the idea. Some were confused. This is where I began to learn a lot about User Experience (UX) and the difficulties inherent in uniting the app model (activities, stats, goals and tracking) with the mental models of a population of users who wanted to track a growing number of things. Many of my users weren’t technical-minded at all.

It was genuinely a fun stage. I got to find out how certain women like to track their weight (down to the nearest ounce?!), how runners enjoy working towards a “pace” goal (per 10k / marathon distance / etc) rather than a speed or time, how some folks expect the app to just “know” what they want to do automatically, and how others expect a power user dashboard presenting to them immediately after sign-up. I also noticed that most of my potential users were baffled by the appearance of any additional UI control / button / option or screen. The extra option, even if labelled “Don’t look at this”, seemed to throw them off. This really was going to need to be a simple and smart app.

A baptism of fire in the UX world, if ever there was one. But, a fun month of learning and revising and repeating demos to try to refine the idea.

I came out of September with a realistic feeling for a slightly scaled-back app, and the confidence that I could actually build something that would appeal to some people and compel them to use it on the goals they wanted to track.

Plan towards Beta – On October 1st, the end of 2012 began to loom ominously in the distance. A seemingly long 3 months away, until you say it as “12 weeks”. So I planned, and did what I’ve always done: lay the tasks out in stages, break them down, and use a massive spreadsheet to add up the estimate and predict the date I could ship a Beta version. This plan also included all of the aspects I had jettisoned from the demo: storage and retrieval of the model (users, goals, etc), deployment (in some as-yet unknown form), security, scalability, and what seemed to be an ever-growing list of new concerns. The UI framework, as-yet unproven, also needed hardening for production use.

With every attempt at solidifying this plan, I added another dimension, another angle, another concern, another thing I’d forgotten about. And each time, I had to jettison another feature that really wasn’t paying its way.

Around October 10th, I had a plan I felt I could work with… and obviously a lot of work ahead of me. But it also felt that this was now a project, rather than just an idea. I had found something worth building, and I could switch from ideas mode back to being an engineer for a while.

In the next few posts I’ll cover the UI Framework, how I chose to host the app, what happened once I reached a Beta version, and the whole thorny issue of users, marketing, payment models and profitability. Hopefully, this post gives you an idea of the process I went through in picking CTS.

Sabbatical year, and ChangesThatStick.com

For the 18 years prior to February 2012, I spent most of my professional time as a software engineer, working in companies big and small in industries as diverse as film & TV, banking/finance, on-line advertising and, most recently, a “big data” start-up. I spent 14 of those years working primarily in Java, both on web applications and on aggressively-scaled server-side systems involved in the capture and analysis of large volumes of data.

In Feb 2012, I decided to take a sabbatical year from permanent employment. Ironically though, I spent most of that year still coding in Java, perhaps even pulling longer hours, but with the freedom to define and build an idea of my own from scratch. That idea became ChangesThatStick.com (CTS), a web & mobile app that I took from concept to Beta and, during the 6-month development of which, I learned a great deal.

One of my motivations for starting this blog was to write about the challenges I faced during that year and how I’ve grown because of them. I also wanted to expose more of the technical details behind a product which, to the external eye, is quite simple but which, as a one-man project, contained more than enough complexity and challenge to get my teeth into.

Why even take a sabbatical? – Several people asked me this just prior to starting it. I figured that, after almost 20 years working on other peoples’ projects, it was time to test my theory that I was capable of creating something from scratch. Even just to find out if I wasn’t. Sometimes, you theorise that you could go it alone but I suspect there’s a danger of becoming a kind of entrepreneurial back seat driver in your regular job if you don’t at least give it a go. I figured that it would also give me heightened respect for the non-software aspects of founding and running a business, as I would get to see them first-hand. It would either result in a viable business, with me running it, or a fresh and more rounded perspective on business upon my return to a regular job.

On hearing about my plans, many folks told me what they would do on a sabbatical year. Most of it seemed to involve escaping: from the UK, from work, from their families or simply doing things they hadn’t done when they were younger and clearly regretted missing out on. I think my reasons were different. This was an exploration of something I’ve always been itching to do, not an escape. Hence choosing days of 12+ hours coding rather than lying on a beach!

Over the next few posts, I plan to cover my choice of CTS as a product, and then dig into some of the technical aspects of it, explaining why this seemingly simple project gave me ample opportunity to explore going it alone.