Buy software or have it developed
Anyone looking for suitable software to solve a problem must make a strategic decision at an early stage: should software be purchased or developed individually? While standard software was developed by a manufacturer for a market or an industry and thus for anonymous customers, individual software is developed on behalf of a specific company. If you ask a software manufacturer who lives from the licensing business, he will probably advise you to buy standard software. If you ask a company that specialises in the individual development of solutions, it will often recommend a custom-made solution. The decision is not easy. Which arguments speak for the purchase and which for the new development of a software? How can you find out whether an off-the-peg suit fits you or whether you need a tailor-made suit?
Established software – the suit often fits
Only a few managers will come up with the idea of having common software – e.g. for creating texts or calculating figures in tables – developed individually. The products that are well known on the market are everyday practice. Even if every company is unique, in most cases the required functionalities are available with the standard programs and the tools as such are not questioned. The company “only” has to decide whether it prefers a standard software or a license-free open source solution.
It becomes much more difficult when the requirements for software increase and application scenarios become more complex. If you are looking for an integrated solution for merchandise management, production, warehouse management and customer databases, you will seldom have them redeveloped. There are too many functions and possibilities off the peg, the development of the products has taken too many years to be able to have something comparable developed individually. As soon as companies think about automation, integration of data from other sources in real time or common user interfaces in such a context, the search for suitable solutions becomes a challenge. What is important here is a suitable process for defining the requirements.
Criteria for decision-making
Which criteria can influence a make-or-buy decision between standard software and individual software, between off-the-peg suit and tailor-made suit? Which points speak for the purchase of a “finished” solution and which for the commissioning of a tailor-made software?
The categorisation “standard software” already reveals it: the software has existed for a long time, it does not have to be conceived, programmed and tested first, instead it is practically directly available. The immediate availability is an obvious plus for standard software. How important is availability? If you need a solution in the long run, immediate availability is not essential. It is sufficient if the software is available at the required time. In addition, availability does not automatically mean that software should simply be implemented in a company. This can easily lead to a lack of acceptance, as described in the article on Factors of software acceptance. Availability can therefore be a plus for standard software, but does not have to be.
Level of maturity
If a software is already used successfully in an industry – over a longer period of time – then this use can be an indication of a higher level of maturity. Possible weaknesses and “teething troubles”, i.e. typical errors that may still be present in younger tools, are generally considered to have been eliminated. A plus for standard software. Have you ever taken a look at a changelog of a software manufacturer? It lists the differences between different versions of a software. In addition to “new features”, you will often find “improvements” and “bug fixes” – usually significantly more improvements and bug fixes than new features. What does this say about the actual maturity level of the software? Perhaps the level of maturity is often not quite as high as it seems at first glance.
Do you think that requirements engineering software is better suited for the management of requirements than e.g. Excel? Would you rather manage customer relationships in a CRM solution or in Outlook? Nowadays there are many tools that have been developed for specific tasks or industries. They offer functions that are exactly tailored to the needs of the users. These features offer advantages “out of the box”. In the case of an individual development, specialisation would also be given, but not “out of the box”, therefore an advantage for the standard software.
Not every available standard software product has a modular structure, but if it offers different modules, features and functional areas can be made available individually. The scaling is done organically and in steps, and therefore not via the number of available licenses. If, for example, you would like to use integrated software that offers you the planning and control of projects, the determination of requirements and the management of issues, you would have the option of addressing the topics one after the other. The acquisition and cost risk is reduced for companies and scaling can be seen as an advantage for standard software. On the other hand, scaling is practically built into an individual development. The development often takes place in agile steps and only when there is a need for further features, the solution is further developed especially for this need. Scaling is therefore merely an advantage of a modular off-the-shelf software compared to a non modular software.
Many tools are prepared for the import and export of data via interface. For example, programs from other manufacturers and data from other solutions can be connected via a REST API. Companies can integrate solutions instead of replacing them. The more interfaces a standard software supports, the greater the advantage compared to order development, because these interfaces have to be developed first. Have you ever tried to exchange requirements between different tools using ReqIF without loss? How well did that work? The existence of an interface does not say much about the quality of the integration. Many standards are interpreted differently by manufacturers. In most cases, the effort required to adapt such interpretations is less than a new development of the corresponding interface, but it will not work without additional effort.
Many programs offer possibilities for customisation. The extent to which a customizing is possible depends on the respective software. Anyone who is involved with the adaptation during the selection of software should clarify what can be changed by whom and with what previous knowledge, and how the options for adaptation are documented. It is therefore not possible to generalise whether the customising options can be regarded as an advantage for standard software.
The features of standard software are often well documented, even if it can be observed that the amount of documentation decreases with increasing technical details. Especially for customising, but also for connecting other tools via interface, documentation is an important point for standard software. Documentation in the course of individual development is occasionally somewhat neglected, especially since many customers are reluctant to pay for the documentation effort. In case of doubt, the development partner has to document the project afterwards and upon request. Documentation is therefore usually a plus point for standard solutions.
Even if manufacturers don’t like to admit it, every software has a lifecycle. If a software is in its introduction, growth or maturity phase, it is in the manufacturer’s interest to improve the software and adapt it to current needs and developments. In most cases, these adaptations are based on the needs of an industry and rarely on the needs of individual customers. Either way, you benefit – at least in principle – from new versions. If the product is in its saturation phase, the frequency of upgrades will decrease, and in the degeneration phase, at best, even smaller updates will be made available. At this point at the latest, companies should consider whether they still need the same amount of maintenance and servicing.
Many providers of standard software have experience and routine in training users. Training concepts and training materials are available and have been tried and tested many times. This helps with the implementation of the software and is a plus for standard software.
The costs for standard software are easy to calculate: The price for a certain number of licenses for a certain number of users, plus maintenance, customising and training. That’s it. In itself, this is similar for individual software, but the manufacturer must first understand exactly what you need, calculate the effort and provide you with a price. One could argue that the manufacturer bears the risk of a misjudgement, but it is not that simple. If he sees an implementation risk, he can schedule a buffer that you pay for. In addition, he will not offer you different licensing models (purchase, monthly or annual rent, pay-per-use). The security in the calculation and the different options speak rather for a standard software. Can you imagine agreeing an iterative process with your service provider with partial deliveries and direct feedback? Why should you assume that you will get something wrong or bad for your money when working in partnership? On the contrary: you receive functions that help you. You don’t pay for a brand name or unnecessary features. If you receive a set of options that will surely offer you what you need, then the security of the calculation is an argument for the individual software.
The tailor-made suit
Of course, not all of the aforementioned reasons speak in favor of standard software. The providers of individual software are also able to clearly identify costs, modularise the software or integrate customising options. The main difference, however, is that all these points must also be created individually. If you need an interface to an existing solution, it must first be designed and implemented. And what happens if you need documentation for this interface – it must also be created individually.
Which points speak – at least theoretically – for the procurement of individual software?
If software is designed for you and thus developed as an answer to a challenge, the result is an innovation. It is unique and tailored to your needs. In the ideal case, you can use it to optimally support your processes, procedures and employees.
Do you know how many functionalities MS Excel offers? There are certainly a lot of them and this is typical for off-the-shelf software products. Manufacturers try to provide features for all conceivable situations. You pay for each of these things, even if you use maybe only 10% of the features. Wouldn’t it make more sense to use software that only provides the features you need?
You need a new, additional feature – for many manufacturers of individual software, this is an elementary component of the business model. Of course, there are costs for the realisation of specific change requests, but these would also arise if a functionality in a standard software would be missing. The difference: with a standard software provider, you as a customer are one of several, perhaps also one of many – so who will usually be more interested in a particularly close, trusting cooperation? For you, this means that your supplier will strive to implement the desired functionality as quickly as possible. Your tailor-made suit will fit even better afterwards.
A little hint: If you adapt an off-the-shelf suit, who can guarantee that it will still fit after an update?
The acceptance of individual software is often greater than that of standard software, because the software is created exactly according to the wishes and ideas of you, your colleagues, superiors and employees. This provides the best possible conditions for software acceptance.
Access to source code
There are occasions when market participants disappear. Manufacturers of standard products find it difficult to deposit source code securely in case of need, so that buyers can access it in the future. When developing individual solutions, this is not an issue at all, because with an appropriate agreement, the source code simply belongs to you. That is maximum security.
Anyone looking for suitable software to solve a problem must make a strategic decision at an early stage. What is your current situation? If you need a working solution within a very short time – then this clearly speaks for the procurement of standard software. The development of individual software usually starts with the cooperation between you and the manufacturer, but the standard software is already available. So if the time factor is essential for you, you can only decide on a standard software, especially since many other aspects in the development of individual software – e.g. documentation or the development of training concepts – will take more time. Anyone who makes a decision must first deal with their own situation and evaluate it.
What about advancements? With standard software, there will be regular upgrades and updates – depending on the lifecycle phase. Here you should make sure that your own adaptations or enhancements also work smoothly with newer versions of the manufacturer. If this is not the case, you should clarify who is responsible for ensuring that your adaptation also works with a new version. Advances in individual software can only be made after prior consultation. The risk described above does not exist.
Do you know who can be a good source for your decision? Your customers, your partners and possibly also your competitors. Who has had good experiences in a comparable situation with whom and what? Who can recommend whom and why? How has the cooperation developed, what speaks for one manufacturer or against another? Perhaps one of your partners already uses software and the exchange between your companies could be even easier in the future.
In summary, it is not easy to make the right decision. When it comes to strategic decisions, that’s a little in the nature of things. This makes it all the more important to deal specifically with the criteria of the decision and to assess the advantages and disadvantages. Good luck with that.
Michael Schenkel has published more articles in the t2informatik Blog, for example
Head of Marketing, t2informatik GmbH
Michael Schenkel holds a degree in business administration (BA) and is passionate about marketing. He likes to blog about project management, requirements engineering and marketing. And he is happy to meet you for a cup of coffee and a piece of cake.