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

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.<p>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.<p>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.

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.<p>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.<p>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.

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 <a href="http://creditcovers.com" rel="nofollow">http://creditcovers.com</a> 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.)

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.<p>I would prefer to write scripts that are useful rather than wasting time, it does not matter if it just suits my requirement.