When 2013 rolled into view I had already completed four-years of working on my own. In shifting to a line of work that is more research and strategy-oriented I figured out that there was tremendous duplication of work and numerous switching of contexts to collect, organize and leverage information.
By then I had tried various approaches — using a variety of tools — to address this problem, but each attempt at it only frustrated me more. To explain the problem, think of your brain as a machine with limited volatile memory and processing power. All the tools only act as physical storage. The pitfalls are rather obvious with this approach.
What I’m building is a framework that approaches this problem from a different angle. What is the approach — I will write more in it as I build more of it. As of now, it is just a set of tacky looking pages and interfaces for entering and managing data. The code has already grown into few thousands of lines and I have only started to scratch the surface with it.
It is fascinating to build something for your own consumption. Most of my development work before this has focussed on getting things built for my clients and building something for myself feels so different. The key thing to watch out for is to not to take any shortcuts and build the system properly. The amount of technical debt that can be acquired at this stage is tremendous.
In a build of this kind, where the end result often can be a moving (almost unattainable) target, the ability to focus is key. The good part about various tools to build things for the web is that there are endless options available to get the same thing done. If you don’t keep simple, bite-sized goals and validate it regularly you can easily lose your way and give up.
When building against a moving target, assumptions, algorithms, logic and outcomes will change. If you don’t validate quickly and adapt to changes that is deemed necessary by the results, the product will become lesser and lesser useful over time. At every stage, what the product does has to match the desired outcome to a great degree.
In the early stages it is very hard to see how the gap between what-is and what-it-has-to-be can be bridged. There will be days when you’ll crank out a complicated feature in a better-than-expected manner in the first go. There will be days when a small simple bug will keep everything held up for a day or days.
Building a product on your own can be both gut-wrenching and unbelievably exhilarating at different times. The key thing is to quickly overcome setbacks and triumphs and keep the longer term goal clearly in mind.