As a developer, I easily get carried away building new things. Side projects are fun for me, especially when they are useful. In fact, I actively avoid programming that is useful only as a learning exercise, like puzzles and tests. Instead of that, I try to build useful things.
The most recent example of this is adding analytics to this blog. Instead of using a service, I've built a rudimentary one from scratch.
Building useful things is more fun for me than just using useful things. In this case, the most interesting part was figuring out how quickly I can build something useful and how far a $5/mo instance on Digital Ocean can take me.
The biggest problem with getting carried away like this is that it sometimes distracts me from writing. That was the case with the most recent article. Instead of spending more time editing it, I got distracted by building my own analytics.
Sometimes this is good since doing a little bit of programming beforehand makes me write more clearly, but often this can be counterproductive. It's counterproductive when I build things that even I stop using after a couple of weeks. In other words, when I build multivitamins for myself.
Most of my previous side projects were multivitamins that I've built for myself.
One example of that is Zapsnap, a temporary image sharing service that I've used for a week and then stopped. Another is Journmail, a service for writing in a journal by sending emails every day. I've stopped using that after a couple of weeks too.
As I was building them, it seemed like they would be useful to me. The ideas were exciting, and I thought I would use each of them, but that ended up not being the case.
The biggest problem is knowing how useful the product will be after it has been built. The idea for the new product is always more exciting than the product I am currently building. The shiny object syndrome is real.
Building multivitamins for myself means scratching my own itch, but this is not the optimal approach. It's problematic because I end up not using the products that I build. In other words, I forget to take my multivitamins.
I wouldn't have this problem had I built aspirins for friends.
Yet, when a friend comes with an actual problem, it's usually a better problem than mine. I don't scratch my own itch, which is contrary to the popular startup wisdom. Still, I actually end up working on a painful problem instead of a minor inconvenience for myself.
The niche of products for developers is really saturated. That's because developers are best at solving problems for other developers. This is the easiest thing to build. But partnering with a non-tech friend and building something for an audience that wasn't yet eaten by software might be a competitive advantage.
Since it's hard to detect a multivitamin and aspirin as I'm building it, it's better to listen to friends who have real problems and try to accommodate them. That's better than inventing problems out of thin air for yourself.
Yet, building aspirins for others is usually not as exciting as building the thing for yourself. At least, it doesn't feel exciting as you're building it. And the worst thing that can happen as you're building it is getting distracted by new ideas for multivitamins for yourself.
* * *
Building aspirins for others instead of multivitamins for myself is a rule for the future I would like to follow. So if I must build something for myself, I better make sure it's an aspirin.