Build or buy software? A decision guide for companies

A fifty-year-old question

In 1976, Computerwoche reported on four users putting off-the-shelf software to the test. Their demand: the package you buy must be cheaper than developing your own, ideally half the price. One of them complained about customisation costs of up to 200 per cent. Fifty years on, that sounds familiar. Today software comes as a subscription from the cloud, and AI writes code in minutes. That changes the sums, but the questions behind them remain: what does the solution cost over its lifetime, who keeps it running, how does the company get out again, and where is the data held? These four points come before any price comparison.

There are three routes to choose from. Off-the-shelf software is quick to deploy, the provider supplies updates and security, but it never quite fits your own processes. In-house development fits exactly, but ties up specialists and attention for years. The third route is customised off-the-shelf software. It looks like a middle way, but has a cost trap of its own: every customisation has to be paid for again with every later update, through testing, dependencies on other modules, knowledge held in a handful of heads, and a harder switch to another system. Customisations should therefore pay for themselves within one to two years and be reviewed annually.

What software costs over its lifetime

The purchase price or the first development contract is only the beginning. After that come maintenance, bug fixing, new requirements, interfaces, training and operations. With off-the-shelf software, much of this sits inside the subscription, and subscriptions are getting more expensive. An analysis of business applications found that two thirds raised their prices by an average of 98 per cent between 2009 and 2019. Anyone buying should therefore ask about price trends over recent years.

With in-house development, maintenance sits in your own budget and in your own people's heads, and it stays behind when the developer leaves. According to a Bitkom survey, Germany was short of around 109,000 IT specialists in 2025, and a vacant IT post remained unfilled for an average of 7.7 months. In a survey of IT decision-makers, a lack of staff was the most common reason for outsourcing development. The honest calculation therefore runs over several years, from the first contract to the exit.

Plan for dependence on the provider

Provider dependence, known in the jargon as vendor lock-in, exists where switching is technically demanding, commercially risky or organisationally close to impossible. Dependence arises in four ways: through technology (proprietary formats and interfaces), contract (long terms, open-ended pricing clauses), data (export only without context) and knowledge (staff who know only this one system). The consequences: price increases with no room to negotiate, operational outages and geopolitical risks, for instance where sanctions cut off access.

In-house development only partly solves this: if you build it yourself, you depend on developers, service providers, platforms and libraries. The remedies therefore apply to every route: secure data export in documented formats contractually and practise it regularly, fixed contractual wording instead of references to provider websites, price caps, and negotiations twelve months before the contract ends. The exit plan is maintained like an insurance policy.

Data protection belongs in the selection process

As soon as software processes names, contact details, salaries or client data, data protection has a say, and that means before you sign. With rented cloud software, the provider processes this data on behalf of the company. That is called processing on behalf of a controller, and the company remains responsible. It may only choose a provider offering sufficient guarantees of technical and organisational protective measures. This includes a written contract setting out the subject matter, duration, purpose, protective measures and audit rights. Sub-processors require the company's consent, and additional rules apply to data outside the EU. Remote maintenance with access to data also falls within this.

With in-house development there is no such contract, but everything sits in your own hands: access rights, encryption, deletion periods, logging, and the question of who installs the security update at the weekend. It gets expensive when these points only come to light after the decision has been made.

AI shifts the sums

AI tools measurably lower the entry price for building your own. In three field experiments with 4,867 developers at Microsoft, Accenture and one large corporation, developers with an AI assistant completed 26 per cent more tasks. Newcomers gained 27 to 39 per cent, experienced developers 8 to 13 per cent. A small study with 16 experienced open-source developers working on their own projects found the opposite: with AI they took 19 per cent longer, yet believed afterwards that they had been faster.

What matters for the decision is what comes after the first lines of code. An analysis of more than 300,000 AI-generated changes across 6,299 projects found at least one new problem in more than 15 per cent of contributions from every assistant. Almost one in four of these was still open in the current version. In the 2025 Stack Overflow survey, 66 per cent of developers were frustrated by solutions that are almost right, and 45 per cent found debugging AI code more time-consuming. And the tools cost money: according to Gartner, 23 per cent of technology leaders spend 200 to 500 dollars per developer per month, and 6 per cent more than 2,000 dollars. By 2028, these costs are expected to exceed the average salary of a developer. Anyone choosing to build in-house needs tests, code reviews and someone who will still understand the AI-generated code in three years' time.

Five steps to a decision

The order matters, and the price comparison comes last.

1. Understand the process: who works with the solution, what does it make easier, and will people be glad to use it? These three questions come first, where the work actually happens.
2. Test the standard option: establish whether an off-the-shelf product covers the core, and whether what is missing is a competitive advantage or merely habit.
3. Calculate over years: for each option, factor in rollout, interfaces, training, maintenance, operations, AI tools and the exit across the planned period of use.
4. Clarify dependence and data protection: settle data export, price caps, contract term, processing on behalf of a controller and the location of the data before signing.
5. Assign responsibility: determine who will look after the solution in three years, who reviews AI-generated code and who decides on extensions. In a provider survey of 817 users, 60 per cent had built tools over the past year without the IT department knowing. That saves time today and costs you the overview later.