Ask HN: Percent of time spent developing internal tools?

First off, such a great question.

I think there is a danger in trying to make your own life too easy at the expense of making your customers lives easier - especially during a startup period.

I think for tools you have to just do the math. If it takes you 10 minutes once a week and the tool you build takes three hours to develop - then the effort will start paying off in 18 weeks. If it takes you 8 hours to build the tool the you don't break even for 48 weeks (almost a year).

There could be other reasons to build a tool, though. For example the process is error-prone and a tool will ensure it is done properly. Or it enables a non-tech staff to take over something that allows them to help customers better.

Lastly one task is always worth automating - that is data backups.

I think Yishan Wong's thoughts on this really hits the mark: http://algeri-wong.com/yishan/engineering-management-tools-a...

It is incredibly important to get your tools right so you can operate as efficiently as possible. At my company we didn't get around to this till much later, partly due to the dilemma you mentioned abt focusing on customer-facing software vs. internal tools, and partly due to the fact that the people who would benefit the most from automation (e.g. finance folks, inventory managers, etc) don't have the same obsession with automating away mundane tasks like us engineers do.

This lack of tools hurt us quite a bit once we started scaling, in ways that impacted some customer relationships (because occasionally we didn't invoice or ship correctly, etc). We have since invested significantly in tools, but we should've done this to begin with.

To make the customer vs. internal tools compromise easier, you may even want to get some basic tools in place via contract work/offshoring and then revisit these later once you have the time/resources. The hard part really is determining what to automate, and how much, and those are decisions that you should make. The development itself can be done by someone else.

As a datapoint: when we (https://circleci.com) did our market research, we estimated that a development team spent about 12% of its time on the parts of testing/deployment that we would replace (mostly setting up a CI server w/ continuous deployment).

A part of the consideration should be the cost of buying the tools. If you have to build all your own tools, there may be another element to the analysis.

Yeah, I worked with something like that about 10 years ago. We had an ETL process that involved like 20 Access macros manually triggered in sequence (click, wait, click, wait...over several days per cycle). I converted this entire process to a Perl script that would be pointed at the raw data directories, clean and process the data and throw it into the DB. Access was taken completely out of the equation. It took a few months, but I was an IT guy who had never programmed before and had to learn Perl at the same time.