Make-or-buy decision

The make-or-buy decision is the structured way to an answer: a weighing-up process that clarifies whether a service is provided in-house (make) or bought on the market (buy). The term comes from classic business administration and has long since moved from the factory floor into IT. There it now decides budgets, team sizes and, not infrequently, the competitiveness of entire business models.

In the software context, the question is concretely: have custom software developed, or introduce off-the-shelf software or SaaS? Both routes work. Both can go expensively wrong. Which one fits depends not on gut feeling but on a handful of criteria that can be checked properly.

Where the term comes from

In business administration, the topic is known as the make-or-buy decision (in German "Eigenfertigung oder Fremdbezug") and is one of the basic questions of procurement and production. A car manufacturer decides whether to make seats itself or source them from a supplier. A mechanical engineering company decides whether to develop the control software in-house or buy it in. The sum of such decisions determines a company's vertical integration and thus a good part of its cost structure.

The question was underpinned theoretically as early as 1937: in "The Nature of the Firm", the economist Ronald Coase argued that companies produce themselves precisely where the transaction costs of buying on the market would be higher than the costs of internal coordination. Oliver Williamson later developed this into transaction cost theory, for which he received the Nobel Prize in Economics in 2009. Translated into everyday terms: buying is not automatically cheaper. Searching, negotiating, adapting and monitoring also cost money; it just does not appear in any quote.

Make or buy in the software context

In IT, the meaning shifts slightly. "Make" means in-house development: software tailored exactly to your own processes. Important here: make does not necessarily mean your own development team. Anyone who commissions an agency or a software company with the development also makes a make decision, as long as they own the code at the end and control further development.

"Buy" means off-the-shelf software or SaaS: a finished product used by many companies with similar requirements, from ERP and CRM to the shop system. A clarification is worthwhile here too. Buy does not mean "no work". Introduction, configuration, data migration and building interfaces cost time and money, in some projects more than the licence itself.

The five criteria that really count

Classic make-or-buy analyses mainly compare costs. For software, that falls short, because the most expensive mistakes rarely lie in the purchase price but in dependencies that only become visible years later. Five criteria have proven robust:

Differentiation is the most important criterion and at the same time the most frequently misunderstood. The rule of thumb: buy the commodity, build the edge. Accounting, payroll, email and video conferencing do not distinguish you from any competitor, so in-house development would be money burned here. The process, on the other hand, with which you deliver faster, advise better or calculate more precisely than the rest of the market is your business. Entrusting it to off-the-shelf software means levelling it down to the standard of all other users of the same software.

Integration surface describes how deeply the new solution has to reach into your system landscape. Off-the-shelf software lives on standard processes. The more legacy systems, special cases and organically grown data structures have to be connected, the more customising the purchased product needs, and customising is exactly the point at which buy projects lose their cost advantages. Beyond a certain number of exceptions, the honest answer is often: a lean in-house development around the existing systems is cheaper than an off-the-shelf product bent out of shape.

Exit path means: you plan the exit before you enter. Can you get your data out again in an open format? Are there documented APIs? What happens in the event of a price increase, a takeover of the provider or a product being discontinued? Anyone who only asks these questions once the contract is running has effectively already lost them. The risk behind it has a name: vendor lock-in.

Maintenance and total costs are decided not by the purchase price but by the total cost of ownership (TCO) over a realistic period, usually three to five years. With make, you bear operation, security patches, further development and the risk of knowledge leaving the company with individuals. With buy, you pay subscriptions that grow with users or revenue, plus customising and upgrades. Both calculations look different in the first year than in the fifth. That is exactly why both have to be drawn up over the same period.

Ownership, finally, is the question of control over the roadmap. With in-house development, you prioritise what gets built. With off-the-shelf software, the vendor decides, and for all customers at the same time. A current example shows how real this risk is: Shopify is finally discontinuing its Scripts feature on 30 June 2026. Merchants who built their discount and checkout logic on it have to migrate to Shopify Functions, whether or not it fits their plans. This is not a criticism of Shopify but the nature of buy: the roadmap belongs to the provider.

A worked example: buy or build a PIM?

A typical case from e-commerce shows how the criteria interact: a retailer with 80,000 items needs a product information management system. Established products such as Akeneo or Pimcore are available on the market, both with an open-source core. The alternative would be in-house development.

Running through the criteria gives a fairly clear result here. For most retailers, maintaining product data is not differentiation but a necessity. The integration surface is manageable, because PIM systems are built precisely for the flow of data between ERP, shop and marketplaces. The exit path is structurally better with open-source products than with proprietary SaaS, because the data model and code are open. And the TCO of an in-house development that would have to compete with mature products would hardly be justifiable. Result: buy, with targeted customising at the edges. The case would only be different if the product data logic itself were the business model, for example for a provider of configurable custom-made products whose set of rules no standard PIM can map.

Typical mistakes in make-or-buy decisions

Most wrong decisions follow recurring patterns:

• Comparing only the purchase price. Setting the licence against the development budget ignores operation, maintenance, customising and exit costs, i.e. most of the bill.
• Buying and then customising to death. Anyone who bends off-the-shelf software until it maps their own special processes pays twice: the licence and, on top of it, a de facto in-house development that breaks with every vendor update.
• Overestimating your own uniqueness. Almost every company considers its processes special. The hard counter-question is: would a customer pay more for this difference? If not, it is not differentiation.
• Underestimating make. In-house development does not end with go-live. Operation, security updates, documentation and dependence on individual knowledge holders belong in the calculation from the outset.
• Ignoring the exit path. As long as everything is running, the question seems academic. It becomes concrete when the price list changes or a feature is discontinued, and then it is too late for a good negotiating position.
• Treating the decision as final. Markets, providers and your own company change. A make-or-buy decision from 2020 deserves a review in 2026, not a defence.

The third way: hybrid instead of either-or

In practice, very few good architectures are pure make or pure buy. The most robust approach combines both: a proven off-the-shelf product as the foundation, in-house development where the business is special. A shop system such as Shopware is bought, while the industry-specific pricing logic, the product configurator or the ERP connection are developed as custom extensions. The off-the-shelf product provides security, updates and an ecosystem; the extensions provide the edge.

Open source is also essentially a hybrid route: you do not buy anything, but you do not develop from scratch either; you take over an open code base and bear the operation and adaptation yourself. And between the systems, a third category is growing: your own integration layer. Anyone using several buy products increasingly develops the middleware that connects them themselves, for example with workflow tools such as n8n. This does not make the make-or-buy question disappear. It just becomes more granular and more honest: not "do we build everything ourselves?" but "which building blocks belong to us, and which do we rent?".

Frequently asked questions about the make-or-buy decision

Is commissioned custom development make or buy?

Make. What matters is not who does the typing but who owns the result. If you own the source code, determine the roadmap and could change the service provider, it is a make decision with bought-in implementation capacity. It is only buy if you use a finished product whose code and roadmap remain with the vendor.

When is off-the-shelf software the wrong choice?

When the process it is supposed to map is your differentiating feature, or when the customising effort reaches the cost of a lean in-house development. A reliable warning sign: the project team talks more about workarounds around the software than about the software itself.

How do you calculate make against buy seriously?

Via the total cost of ownership of both variants for the same period, usually three to five years. On the make side, include development, operation, maintenance and staffing risk; on the buy side, licences or subscriptions, introduction, customising, upgrades and the estimated exit costs. Only when both calculations are complete is the comparison fair.

Is there a middle way between make and buy?

Yes, and in practice it is the norm: off-the-shelf software as the basis, in-house development for the business-critical special features, plus open source and self-developed integration layers. The question then arises not once per company but per building block of the architecture.

How often should a make-or-buy decision be reviewed?

At every major trigger: a change of pricing model or a discontinuation by the provider, significant growth, new regulatory requirements or a change of strategy in your own company. As a rule of thumb, a short review every two to three years is worthwhile, even without an acute reason.