Overcoming the Build Bias

2012-03-24 2 min read

    An issue I’ve been trying to overcome is what I like to call the “build bias.” Whenever I’d run into a technical problem, I’d want to solve it on my own - whether it’s by writing some code or by installing and configuring various libraries and packages. I remember the time I needed to collect feedback for a website but instead of just using an off the shelf product like GetSatisfaction, I decided to create my own. Although I was able to get it working, it took me longer than expected to get it into a usable state and distracted me from the other improvements I wanted to make.

    As a developer, it’s very easy to convince yourself to build from scratch every time you need something rather than using an existing solution. It’s exciting to work on something new and it’s annoying integrating someone else’s code. It’s even worse when they’re charging a few dollars a month for something that you can build in a few hours.

    More often than not we underestimate the cost of building something of sufficient quality and don’t include the ongoing maintenance cost we’ll most likely be doing. More importantly, we are no longer focusing on the highest leverage activity. As they teach in business schools, you shouldn’t outsource your core competency but everything else is fair game. This is also supported by the lean startup approach which encourages getting your product to market as soon as possible so you can validate your market hypotheses. Why spend time building features when you don’t even know you have a marketable product? If it does turn out that you have a successful product you can always go back and develop your own solution then.

    My new process is to first make sure that the feature is even needed. If it is, I check out the open source alternatives to see if anything can be used. If not, I look at the available paid solutions. For many small projects, it turns out that you can ride the trial/basic version enough to validate your idea. This approach has led Glossi to use MongoHQ to host my database, SendGrid as my email system, and GetSatisfaction as a feedback widget in addition to ton of open source libraries. With every new project, I’m offloading more and more of my auxiliary features to cloud based services and feel much more productive. Makes me wonder how many other services there are out there that can be leveraged.