German buyers ask us the same question, almost always in the same words: custom software or a package? The words are not marketing. Custom software is written for one client. Off-the-shelf software is a product many companies configure the same way. The question usually arrives after a Salesforce, SAP, or vertical-tool quote is already on the table, and after someone internally has said you could "just customize it".
We build custom software. That makes us biased. It also makes us the party that says no most often. A large part of our software consulting is telling a founder or IT lead why a package is the better first answer. The rest is finding the cases where the package is the more expensive lie over three years.
When a package is the right answer
A package wins when your process looks like the market. Accounting looks like accounting. A CRM for a classic inside-outside sales model looks like a thousand others. Project tracking without industry-specific mandatory fields does too.
In those cases you are not only buying software. You are buying the vendor's process, updates, training material, and a community that has already sanded down the same edges. That is valuable. Bitkom's recurring picture of unfilled IT roles in Germany is a useful reminder that internal engineering time is scarce. A package is a way not to spend scarce developer hours on solved problems. The Bitkom survey on unfilled IT jobs is the right backdrop: ordering custom work for commodity processes buys you into a shortage the market already has.
Three tests that a package is enough:
- Can you bend the process to the software without losing the margin?
- Do more than two thirds of the packaged features stay switched on?
- Does the critical integration sit in a vendor-documented connector, not a one-off?
Three yeses: buy. Do not build.
When custom is cheaper over three years
Custom pays when the process itself is the difference versus competitors. A dispatch algorithm nobody else can subscribe to. An underwriting flow that knows your claims history. An operating sequence no vertical package covers because your customers demand it that way.
Then a package is not a saving. It is a tax on every deviation. Each deviation becomes a plugin, a custom object, an expensive integrator day. Eighteen months later you have paid like custom and still do not own the core.
We run build vs buy over three years, not against the first quote. In the scoping calls we sit in, the spreadsheet usually tips on three lines:
- Licenses plus seats. What looks friendly in year one scales with heads, transactions, or connected systems.
- Customization. The integrator sells "configurable". Configurable ends the moment your mandatory field is not in the data model.
- Process breakage. Someone in operations works around the system, in spreadsheets, because the package does not map the real flow. That shadow IT is part of full cost even when it never appears on a license line.
Our Germany app-development cost guide shows what a custom build typically costs in this market. For 2026 rates, inclusions, and how to choose who builds it, see our custom software development guide for Germany. Our quote comparison shows how to normalize custom quotes before you lay them next to a license. Both belong in the same table.
The expensive middle: a package that feels custom
The failure we clean up most often is not "we built custom and should have bought". It is "we bought a package and then customized it until it was custom".
Typical pattern: a CRM or ERP goes live in the default configuration. After six months come mandatory fields, special pricing, a hook into an old warehouse system, an exception for the largest customer. After twelve months, custom code sits on a foreign core. Vendor release notes become risk dates. The data model still belongs to the vendor.
At that point you have three bad options: keep paying and hope, freeze the custom share, or cut it out and rebuild. Cutting it out costs more than the build you declined in year one. That is why "what has to live in our repo?" belongs at the start, not in the exit conversation.
A decision in 90 minutes, not 80 slides
Build vs buy does not need a strategy offsite. Three questions, on one sheet, with the people who actually run the process in the room:
Which process creates the margin? Everything else is commodity until proven otherwise. Commodity you buy.
What are you willing to change if the software demands it? If sales can rebuild the flow, a package is almost always right. If the customer dictates the flow, custom is the default.
What has to be yours if the vendor doubles prices? Code, data model, integrations, training data. Whatever is on that list must not sit inside a license you do not control.
Whatever is still unclear after 90 minutes is the custom candidate. Not the whole company. One process. Scope it tight, like an MVP, and leave the rest as a package.
If you already have quotes, send us the scope and the license model. We will tell you which line is custom and which you should buy: Talk to us.
Frequently asked questions
Is custom software always more expensive than off-the-shelf?
In year one, usually. Over three years, often not, once licenses, customizations, integration work, and the internal cost of bending your process to the tool are in the same spreadsheet. Compare full cost, not the agency quote against the vendor list price.
When is off-the-shelf software enough?
When your process looks like the market: accounting, a CRM for a classic sales team, project tracking without industry-specific mandatory fields. If you would have to switch off or rebuild more than a third of the packaged features, you are no longer buying a package.
Can you customize a package until it replaces custom software?
Technically yes, economically rarely. Every layer of custom code on someone else’s core ties you to their release cycle, license model, and a data model you do not own. Two years in, teams often pay the cost of both worlds.
How do you decide build vs buy in a workshop, not an 80-page report?
Three questions: Which process creates the margin? What are you willing to change if the software demands it? What has to live in your repo if the vendor doubles prices tomorrow? Whatever is still unclear after 90 minutes is the custom candidate.
