PUBLISHED 1 JULY 2022

Develop In-House Or Buy Off-The-Shelf?

Naturally, as a software development company that operates solely within the logistics market, we believe that in the majority of cases the most common sense and logical action is to purchase Warehouse and Transport Management Systems “off the shelf”.

You may well think “they would say that, wouldn’t they”, but if you do read on, we believe you will find the following discussion to be well balanced in its views, and justify why we believe that to be the best decision in the vast majority of cases.

A company will usually develop in-house where the issue to be addressed is trivial or where their requirements are viewed internally as complex, or perhaps unusual – a “we do things differently” mentality. Alternatively, maybe the IT department is seen as a fixed, or “sunk”, cost to the business and using them to develop a new software solution may be a “cheaper” option.

If we ignore the former and move on to the possibility of the complex and unusual, the realisation of software projects range from the totally in-house development through to the totally off-the-shelf purchase.

With a product developed completely internally, the requirement is defined, analysed, programmed, maintained and developed using the company’s own resources. In contrast, with an off-the-shelf commercial offering, you will buy and effectively have to work with the package as it comes out of the box. In reality you are least likely to find total solutions for logistics software in either of those extreme positions.

In many cases there will be a large degree of external involvement in achieving the eventual outcome. External consultants, system analysts, programmers and project managers might be used to deliver a ground-up in-house product, while no sophisticated commercial product is likely to be useable without some configuration and tailoring to meet a customer’s specific needs. This is often in close co-operation with internal IT staff, and it should also involve working with the relevant operational staff. These are elements of best practice that we always follow at Clydebuilt Business Solutions.

More realistically, the comparisons are the perceived benefits of Bespoke Software versus those of a Tailored Commercial Package. The crux of the matter comes down to the hope that the core of the chosen pre-packaged product(s) will be tried and tested, more robust and providing a stable basis on which local workflow procedures and processes may be built. This means that even if the given methods and mechanisms that augment the core are initially less than required, the system can function, probably very successfully, whilst additional changes are made. It is the combination of this strong, stable and very capable core, with the flexibility to tailor and add functions and procedures quickly, that characterise the modern commercial logistic software package, such as those that we provide at CBS. By comparison, in-house developments can rarely afford to build in additional capabilities that are not immediately required and, of course, some additional capabilities may not even be thought of.

Further developing the in-house system with new, even minor changes, can be slow and costly to deliver.

The commercial product on the other hand is likely to be the result of a variety of users in different environments all bringing their needs and requirements to the product design table. There may well be generations of design involved, making it possible that future requirements, currently unknown or vaguely known, are already catered for or easily added. With an external package you may also be entitled to any upgrades and improvements that are made to the product along the line, with negligible or no extra cost.

None of the above touches on the problems of being locked-in to external consultants that can follow a bespoke program or the difficulty of supporting and amending a system when the original programmers have gone and the level of documentation is often inadequate for others to take on the development without a huge time commitment.

There are pros and cons to both sides of course, with regards to where your software products are coming from, and these will be discussed in further detail in the next blog.