Buy software or have it developed

by | 09.11.2023

You are faced with a strategic decision: “Should we buy software or have it custom developed?” The question is extremely tricky, as both the purchase of standard software and the development of a customised solution have advantages and disadvantages, and you often (have to) live with your decision for several years.¹

If you ask a standard software manufacturer who makes a living from the licence 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 customised solution. Such recommendations won’t really help you. What will help you, however, are detailed arguments in favour of both options in order to make the right decision for your company.

Standard software: the off-the-shelf suit

Let’s start with standard software. This is developed by manufacturers for a broad market or a specific industry and is therefore intended for numerous, usually anonymous customers. In many cases, off-the-shelf software is already established and offers the required features and functions. For simple tasks such as word processing or spreadsheets, purchasing standard software is often the best choice. The products available on the market usually fulfil the requirements of most companies, so you “only” have to choose between different manufacturers and offers. A step-by-step software selection helps here.

The decision becomes more difficult when your individual requirements for a solution increase and the application scenarios become more complex. If you are looking for a solution for production planning and merchandise management, you will rarely have it developed from scratch; there are too many off-the-shelf functions and options, and it has taken too many years to develop the products to be able to have something comparable customised. However, as soon as you start thinking about integrating additional tools and data from other sources or a common user interface in such a scenario, the search for standard software (or the decision in favour of customised development) becomes a challenge. A suitable process for defining the requirements is important here.

Criteria for decision-making

What criteria can influence a make-or-buy decision between standard software and individual software, between an off-the-shelf suit and a tailor-made suit? Which points speak in favour of buying a “ready-made” solution and which speak in favour of commissioning custom-made software?

Let’s take a detailed look at the following criteria:


The categorisation “standard software” already gives it away: the software has been around for a long time, it doesn’t have to be designed, programmed and tested, but is practically immediately available. Immediate availability is an obvious plus for standard software.

How important is availability to you? If you are looking for a prospective solution, immediate availability is not essential. It is sufficient if the software is available when you need it. Furthermore, availability does not automatically mean that software should simply be introduced into a company. Here you should consider the factors of software acceptance.

Availability can therefore be a plus for standard software, but it doesn’t have to be.

Maturity level

If software has already been 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 weak points and “teething troubles”, i.e. typical errors that may still be present in younger tools, are generally considered to have been eliminated.

Have you ever taken a look at a software manufacturer’s change log? It lists the differences between different versions of the software. In addition to “new functions”, you will often find “improvements” and “bug fixes” – usually significantly more improvements and bug fixes than new functions. 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. However, this cannot be ruled out when developing individualised software:

A plus in favour of standard software.

Modularity and scaling

Not all standard software has a modular structure, but if it offers various modules, functions and functional areas can be customised. Scaling takes place organically and in steps, and therefore not via the number of licences available.

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 in favour of standard software.

On the other hand, scaling is practically built into customised development. Development often takes place in agile steps and only when there is a need for additional functions is the solution further developed specifically for this need. Scaling is therefore merely an advantage of modular off-the-shelf software compared to non-modular software.


Many tools are prepared for the import and export of data via an interface so that you can integrate solutions instead of replacing them. The more interfaces a standard software supports, the greater the advantage over customised development, as these interfaces would first have to be developed.

Have you ever tried using ReqIF to exchange requirements between different tools without loss? How well did that work? The existence of an interface does not in itself say much about the quality of the connection. Many standards are interpreted differently by manufacturers. In most cases, the adaptation effort required to harmonise such interpretations is less than a new development of the corresponding interface, but it will not work without additional effort.

Advantage: Standard software, provided the required interfaces are available and function as desired.


Many programmes offer customisation options. The extent to which customising is possible depends on the software in question. Anyone considering customisation when selecting software should clarify what can be changed, by whom and with what prior knowledge, and how the options for customisation are documented. It is therefore impossible to generalise whether the possibilities of customisation can be considered an advantage for standard software.


The functions of standard software are often well documented, even if it can be observed that the scope of the documentation decreases as technical details increase. Documentation is an important point for standard software, especially for customising, but also for connecting other tools via an interface.

Documentation in the course of individual development is sometimes somewhat neglected, especially as many clients are reluctant to pay for the documentation effort. In case of doubt, the development partner must provide documentation retrospectively and on request. Documentation is therefore generally a plus point in favour of standard solutions.

Care and maintenance

Even if manufacturers don’t like to admit it, all software has a life cycle. 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 orientated to the needs of an industry and rarely to 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, smaller updates will be made available at best. At this point at the latest, you should consider whether you still need the same level of support and maintenance.

Note: Two years ago, very few users would have thought that the care and maintenance of common tools such as word processing or spreadsheets was really necessary; with the advent of artificial intelligence, this assessment has probably been refuted. The question you need to answer in the course of care and maintenance is therefore: How important is care and maintenance in your specific situation and to what extent does the standard software manufacturer or the software development service provider offer both?


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 introduction of the software and is a plus for standard software.


You can calculate the costs for standard software relatively easily: the price for a certain number of licences for a certain number of users, plus maintenance, customising and training. That’s it.

This is similar for individual software, but the manufacturer must first understand exactly what you need, calculate the effort involved and give you a price. You could argue that the service provider bears the risk of a miscalculation, but it’s not quite that simple. If they see an implementation risk, they can include a buffer that you pay for. In addition, they will not offer you different licence models (purchase, monthly or annual rental, pay-per-use). The security of the calculation and the various options are more in favour of standard software.

Can you imagine agreeing an iterative process with your service provider with partial deliveries and direct feedback? Why should you expect to get something wrong or bad for your money when working in partnership? On the contrary: you get features that help you. You are not paying for a brand name or unnecessary functions.² If you receive a set of options that is sure to offer you what you need, then the certainty of the calculation is an argument in favour of the individual software.

Individual software development: the tailor-made suit

Many, but not all, of the above criteria speak in favour of standard software. Providers of customised software are also able to clearly state costs, modularise the software or integrate customising functions. The main difference is that all these points have to be created individually. If you need an interface to an existing solution, this must first be designed and implemented. And what happens if you need documentation for this interface – this also has to be created individually. What points – at least in theory – speak in favour of procuring individual software?


If software is designed for you and thus developed in response to a challenge, the result is an innovation. It is unique and customised to your needs. Ideally, it will optimally support your processes, workflows and employees.

Functional coverage

Do you know how many functions MS Excel offers? There are certainly a lot, and this is typical of off-the-shelf software products: manufacturers try to provide functions for every conceivable situation. You pay for each of these functions, even if you only use 10% of the functionality. Wouldn’t it make more sense to use software that only offers the functions you need?

Function extension

You need a new, additional function – for many manufacturers of individual software, this is an elementary part of the business model. Of course, the realisation of specific change requests incurs costs, but these would also be incurred if a function were missing from standard software. The difference: with a standard software manufacturer, you as a customer are one of several, perhaps even one of many – so who will generally be more interested in a particularly close, trusting collaboration? For you, this means that your supplier will probably endeavour to implement the desired functionality as quickly as possible. Your tailor-made suit will then fit even better.

Access to the source code

Sometimes market players disappear. Manufacturers of standard products find it difficult to securely store source code just in case, so that you can access it in the future if necessary. When developing customised solutions, this is not an issue at all, as the source code simply belongs to you with the appropriate agreement. That is maximum security.


User acceptance is often greater with individualised software than with standard software, because the software is created exactly according to the wishes and ideas of you, your colleagues and employees. This provides the best possible conditions for software acceptance.


If you are looking for suitable software to solve a problem, you have to make a strategic and often tricky decision.

What situation are you currently in? If you need a functioning solution within a very short space of time, then this clearly speaks in favour of procuring standard software. The development of individualised software usually only begins through cooperation between you and the manufacturer, but the standard software is already available – with a certain degree of maturity. So if time is of the essence for you, you can only opt for standard software, especially as many other aspects of individual software development – such as documentation or the creation of training concepts – will take additional time.

What about further developments? With standard software, there will be regular upgrades and updates depending on the life cycle phase. Here you should make sure that your own customisations or extensions also work smoothly with newer versions from the manufacturer. If this is not the case, you should clarify who will ensure that your customisation also works with a new version. Further developments of customised software are only possible after prior consultation. So the risk just described does not exist; plus point: bespoke software.

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 with what?
  • Who can recommend whom and why?
  • How has the cooperation worked out, what speaks in favour of one manufacturer or against another?

Perhaps one of your partners is already using software and data exchange between your companies could be even easier in the future.

To summarise, it is not easy to make the right decision. With strategic decisions, this is somewhat in the nature of things. This makes it all the more important to analyse the criteria for the decision and assess the advantages and disadvantages. Good luck with this.



Are you faced with the decision “Buy software or have it developed?” Talk to us about your situation and we will be happy to support you with our honest assessment.

[1] In practice, two concepts often clash here: the amortisation of a decision and the concept of sunk costs. In business administration, sunk costs are costs that a company has incurred and cannot recover through future decisions. Sunk costs may rationally not be taken into account for future decisions.
[2] It is said that around 60% of software functions are not or hardly ever used. You usually pay for these functions when you purchase standard software.

The article does not go into the weighting of the various criteria. So if you are in the situation of wanting to make a decision, you can achieve different results by weighting individual aspects.

If you like the article or would like to discuss it, please feel free to share it in your network.

Here you can download a Software Implementation Whitepaper to take with you.

Michael Schenkel has published more articles in the t2informatik Blog, for example

t2informatik Blog: Requirement analysis, but remote

Requirement analysis, but remote

t2informatik Blog: Eliminate requirements

Eliminating requirements

t2informatik Blog: The "why" in requirements engineering

The “why” in requirements engineering

Michael Schenkel
Michael Schenkel

Head of Marketing, t2informatik GmbH

Michael Schenkel has a heart for marketing - so it is fitting that he is responsible for marketing at t2informatik. He likes to blog, likes a change of perspective and tries to offer useful information - e.g. here in the blog - at a time when there is a lot of talk about people's decreasing attention span. If you feel like it, arrange to meet him for a coffee and a piece of cake; he will certainly look forward to it!​