I’ve been working on my burgeoning web service idea for just over a year now and I’m finally at the point where I feel like I’m actually making in roads into a fully usable system. It took 3 complete code dump and rewrites to get to this point but I’m finally satisfied with the way it works and how the client has turned out. Each iteration brought with it a rethink of what the application was going to be and a much better focus on what would be important to it. The decision to dump the last code base and start anew was probably the best decision I’ve made in a long time as the resulting product from it is strongly focused on what initially drove me to build this application.
Still after diving head first into the world of handset programming I can’t help but feel that I might have been going about this the wrong way. I initially started coding up the web client first because it would be the easiest of the lot and would ensure that I had the majority of the APIs working properly before I tried my hand at coding for a completely different platform. For the most part that was true as the API I have created facilitates all the functions I require and will work across platforms so long as they’re able to access the Internet. However had I developed a handset application first instead of going for the web client I would have been forced to make some of the hard decisions quite a lot earlier, possibly saving me those 3 code dumps that led to the current incarnation.
You see the first 3 versions I created were heavily focused on the idea of aggregating information around a particular location. I did this mostly because it was a good programming exercise and got me thinking in right direction for coding services destined for the Internet. At the same time however it had me lost in adding in numerous information streams all of which took a significant amount of time to implement. In the end once I got to the core feature that had been rattling around in my head (that whole location based communication thing) it was lost amongst the noise of the other features and the small trials I did with people didn’t even notice it as a feature.
After taking a month long break from coding I had a look at what I was doing and knew that it needed to change. This, I have found, is referred to as a pivot:
That’s the pattern we see in so many successful startups. They did everything they could to take advantage of what they’d built so far. Most engineers naturally think about repurposing the technology platform, and this is a common pattern. But there are a lot of other possibilities. I’d like to call out three in particular: pivot on customer segment, pivot on customer problem, or pivot on a specific feature.
In particular I was pivoting on a particular feature. Up until that point all I had been doing was finding an information feed and adding it in as an option. The core location based messaging feature became an afterthought but that was the hook with which I felt people would find the most use for it. After reading countless articles and looking to those who had come before me for inspiration I knew that if I intended to use such a feature as the main draw it had to actually be the most prominent aspect of the application. Thus Lobaco was born and I feel as if I’m finally taking steps in the right direction, rather than stumbling in the dark.
Working first on the handset would’ve forced my hand with this as you can’t afford to have a scattered focus when you’re working with such a limited environment. Still the lessons learned from those failed attempts have proven to be quite valuable and the coding experience wouldn’t have come any other way. It’s quite possible that I might have been a lot further down the track had I gone for a handset first but that’s not something I’m going to dwell on. Right now I have 3 handsets and a web front page to code up and I’m looking forward to doing each and every one of them.