Make or buy: purchase standard software or build custom?

Make or buy is the oldest question in corporate IT — and it's almost always framed wrong. Because in practice the answer is rarely "buy" or "build". It's: buy, and close the gap.

Classic make-or-buy comes from manufacturing: cast the cylinder head yourself or source it? With software, that either-or logic leads astray, because software can be combined. Nobody has to rebuild DATEV to improve a DATEV process. Yet that's — in essence — what an astonishing number of requirement documents we get to see are asking for.

We've watched this debate on many tables since 2018 — at tax firms, in trade businesses, in machine building. One thing stands out: the decision is rarely made rationally. Sometimes fear of dependency pushes towards building, sometimes IT leadership pushes towards standard because they dread the maintenance burden. Both are legitimate worries — but neither is a basis for a decision. Which is why we've broken the question down into four testable sub-questions.

Four questions that carry the decision

When a make-or-buy question lands on our desk, we walk through four questions. In this order, because each question can make the next one unnecessary.

1. Is the process commodity or differentiating? Accounting, payroll, email: commodity — buy practically always wins here. The process that sets you apart from your competition, on the other hand, is a make candidate. Whoever takes their differentiator out of the standard drawer has, by definition, none.
2. Does standard software cover at least 80%? And — more importantly — is the missing 20% negotiable? Sometimes it's cheaper to adapt your own process to the tool than the other way around. Sometimes, though, that 20% is exactly the part the business hangs on.
3. How stable is the process? Building your own pays off for processes that have settled. Whatever reinvents itself every quarter is better off in configurable standard software.
4. What does the gap cost per week? Only this number makes the discussion honest. A gap that costs ten hours of manual work per week justifies different money than one that's annoying once a month.

The four questions sound simple, but they settle most discussions surprisingly fast. In practice, make-or-buy debates rarely fail for lack of analysis — they fail because question one was never asked. Once a company has said out loud that its payroll is not a differentiator, half the requirements document dissolves by itself.

The third way the textbook leaves out

Most real cases we've seen since 2018 are neither make nor buy. The standard system is long in place — SAP, DATEV, Shopware, an industry ERP — and it works at its core. What's missing is a piece. Three patterns from real enquiries:

• SAP Business One has been running for years, but the field staff retype orders into Excel in the evening because the module has no offline capture. The answer wasn't "replace SAP" but a small capture app that writes into SAP through the official interface.
• A Shopware shop with a standard warehouse connection, but customer-specific pricing logic: volume tiers, contract discounts, individual terms. Instead of rebuilding the shop: a lean pricing engine as an API layer in front of it. The shop itself stayed untouched.
• A tax firm on DATEV whose clients send receipts via WhatsApp and email — someone matches and renames every receipt by hand. The solution is an importer that reads, matches and uploads to DATEV. How such a document automation works, we've described separately.

In all three cases the purchased system remained the foundation — and a small, custom piece of software closed the gap. Price point: patch or module size, not platform. That's almost always an order of magnitude cheaper than replacing the system, and it risks nothing of what already works.

The third way has a side effect we initially underestimated: it's reversible. If you build next to the system, you can replace, extend or switch off the small tool without the core business noticing. If you've replaced your system, you no longer have that option — migration is a one-way street.

When buy clearly wins

So this isn't misunderstood: we earn our money with custom software — and still our advice often starts with "buy that". The clear buy cases:

• The process is commodity and identical across the industry — accounting, payroll, calendar, email.
• An established vendor shares the compliance burden: GoBD, GDPR, certified interfaces.
• You need the result in weeks, and the process can reasonably adapt to the software.
• The actual problem is usability, not missing functionality — new software won't solve that anyway.

When make wins

On the other side, there are constellations in which standard software is, over time, the more expensive and weaker choice:

• The process is your differentiator — the reason customers pick you over the competition.
• The gap measurably costs hours per week, and no vendor has it in their catalogue.
• Standard software would only fit with deep customizing — and deeply customized standard software is the most expensive form of custom software, with update pain on top.
• You want to own the data and the code, without licence lock-in and without vendor dependency.

The five-year calculation both camps forget

The most common mistake on the buy side: licence costs are thought of as one-off. They aren't. Per user, per month, a little more expensive every year — over five years, with thirty users, a six-figure sum adds up quickly, for software that still won't belong to you at the end. On top come the silent items: customizing contractors, training, and the working hours your team spends manually bridging the remaining gaps.

The most common mistake on the make side: the build is thought of as the end point. It isn't. Software lives — hosting, security updates, adjustments when a connected system changes. Whoever calculates custom software should budget maintenance as an annual item from the start. So the honest comparison is never "purchase price versus build price" but: five years of total cost against five years of total cost — including the manual work that every open gap costs, week after week.

We thought we needed a new ERP. We needed a warehouse app and two interfaces.Paraphrased from several first conversations over the years

A word on deep customizing

The most expensive route is almost always the apparent compromise: buy standard software and then bend it until it fits. That brings the downsides of both worlds into the house — you pay for licence and development, still don't own the code, and every vendor update becomes a nail-biter because nobody knows whether your modifications will survive it. When the necessary adjustments go beyond configuration, that's the clearest signal for us to close the gap outside the system — next to it, through the official interface, with your own code.

Our recommendation, as a sequence

1. Buy what's commodity — and keep it as unbent as possible.
2. Configure instead of customize. Every deep modification to standard software is paid for again with every update.
3. Close gaps with small, custom tools next to the system — through the official interfaces.
4. Build only what sets you apart — but then properly: with discovery up front and ownership of the code.

This sequence is unspectacular, and that's exactly the point. It prevents the two expensive extremes: the five-year "new ERP" project that ends up with gaps anyway — and the sprawl of twenty island solutions nobody maintains anymore. In between lies a portfolio of purchased foundation and a few targeted custom builds. That's the target picture for almost all of our clients.

How we think about such projects in three sizes — patch, module, platform, with public price ranges — is on our studio page. And if you're facing exactly this decision right now: in the first conversation, make-or-buy usually answers itself.