All things being equal, a technology developed for and sold to an external audience is going to be superior to an internal tool fulfilling the same role. After all, the captive marketplace is not known for its ability to produce high quality goods. Time and money spent developing tools used only by other engineers in the same group or company is essentially pure overhead (“muda” if you’re of the lean software persuasion).
Alas, many of us must put up with this waste in order to produce value at least in the initial phases of a project — especially in large scale or highly specialized systems where “off the shelf” tools won’t cut it. But it need not stay that way forever. When a legitimate need exists which is not otherwise fulfilled by the prior art, a product could be born. Rather than hack together a barebones, barely-working tool, what about trying to build something that a normal human being might want to use, and perhaps even pay real money?
As a special bonus, “productized” technologies tend to receive more attention to detail (fewer annoying workarounds) and ongoing maintenance (less time spent reacting to broken features and general disrepair). They may even have clearly thought out use cases and a consistent design philosophy, if they hope to win the hearts and minds of consumers who have a choice in the matter.
This is not to say that all engineering tools should be assigned a Director of UX and a marketing budget. Quick hacks and simple scripts do the job fine when the job is short-lived and constrained in scope. However, anything strategically important to your engineering process ought to have a “productization” bent, lest it perish due to neglect or implode under its own weight.