Ask HN: Do you build tools whose end user is just you?

2 points by bluepanda_ 12 years ago | 8 comments

Is it worth spending a considerable amount of time implementing a tool that meets the very specific requirements that you need, but which, as a result, may leave you as the single end user of the product? Or do you just, in this case, use tools that have already been developed, even though they don't meet the exact requirements that you need?

Obvious advantages of developing such a tool are that the resulting product is just what you need, and it can therefore radically boosts your productivity. Another advantage is the experience you gained developing it.

Disadvantages are that it only benefits you, and you cannot make any money from it or help other users.

mindcrime 12 years ago |

I do, yes. I try not to do it terribly often, because I don't want a pile of one-off tools to support, especially if they aren't something we're ever going to make into a product and generate revenue from. But sometimes, the needs are just so unique and there just isn't anything else out there that quite fits.

The most notable example for us is FUCIT - Fogbeam Universal Competitive Intelligence Tool. As you might guess, it's our dashboard for locating, exploring, cataloging, and analyzing competitive intelligence. There really wasn't anything out there that met the required combination of: features, functionality, price, license, technology stack, etc. So I cobbled FUCIT together as a Grails app over a week or two.

I don't really think we'll every try to make a product out of it, and since the code itself isn't really a source of competitive advantage, I am leaning towards open sourcing it eventually. I'd do it now, but A. I want to fix a few bugs and tweak a few more things first, and B. it just isn't a priority. But if we do ever release it, at least maybe somebody else will get some value from it, and maybe some other people will get involved in helping maintain / improve it over time.

bluepanda_ 12 years ago | |

Open-sourcing it would be a good idea, as other developers could potentially fix it for you.

inetsee 12 years ago |

What you need to do is determine how much time a script or tool will save you, how often you perform the function the script or tool will help you with, how long it will take you to develop the script or tool, and how long you are willing to wait for payback.

E.g. If it takes you an hour to develop a script, it saves you five minutes every time you use it, and you use it every day, then your break even point is 12 days. Alternatively, if you use the script once a month, then your break even doesn't come for a year. You have to decide whether to invest time now, to save yourself time in the future.

Developing a more general tool that might help others or turn into a revenue generating product, will almost certainly involve a much larger investment of your time, with an indeterminate reward. Making the decision to proceed with a project like that is a much more complex calculation.

bluepanda_ 12 years ago | |

Thanks for quantifying it, that will be useful.

ada1981 12 years ago |

Consistently. I think this is one of the best applications of being able to program -- is solving your problems with it. A recent automation program I wrote will save one of my businesses about 365 hours a year and will boost customer satisfaction. (I automated a process on http://creditcovers.com that would take about an hour a day, but I hated doing it, so I would often put it off and then sporadically batch it, which led to lots of unhappy customers. Now it happens every day at 2am automatically and it is really an incredible improvement to my life.)

bluepanda_ 12 years ago | |

Congrats, that's amazing!

deepak-kumar 12 years ago |

I think you have already mentioned the pros and cons here and you are very much right. I am a bit lazy developer and hate doing the same things again and again knowing the fact that the process can be automated. Though believe in sharing knowledge. The first thing is your tool must serve well to your need. Making the tool generic enough is later part of the story.

I would prefer to write scripts that are useful rather than wasting time, it does not matter if it just suits my requirement.

bluepanda_ 12 years ago | |

That makes sense. Thank you.