One of the quickest ways to get a new internal tool bootstrapped is to utilize an existing design, making slight adjustments to ensure the design matches the requirements of the current project. Instead of using another internal tool as the basis for the new design, I used a design that was purchased specifically for this project.
If you think that this web designer is the only culprit for this type of missing documentation, lets take the major eCommerce platform Magento as an example. While there are many tutorials for the end user to setup and manage their online store, there is very little from the Magento project itself about how to extend Magento’s functionality. While there are quite a few blogs, including this one, that appear in search results for how to implement small pieces of functionality in Magento, there is no user-friendly documentation about Magento and how to properly extend it, leading to wildly-varying ideas of what the ‘Magento way’ of doing something is.
Any seasoned developer will tell you that you can judge the quality of a software project based upon the documentation it provides to other developers that must use or maintain the project long after the original developers are no longer involved. In the two scenarios above, they each offer some extremely nice functionality that is time consuming to replicate, yet they fail to make it as easy as possible for future developers to pick up the project and utilize and extend it.
As a result, many time the experienced developer’s gut reaction to the question of whether you build something yourself or buy it off the shelf is that you should always build it yourself. Either way, there will be defects in the finished product, but with the solution built in-house, at least you have some control over the architecture and maintainability of the solution, easing the burden of resolving issues when they arise.