The question is usually asked as if a company must pick a side. In practice almost every German business already runs both. Nobody writes their own payroll system, and nobody buys a standard product for the process that makes them different from their competitors. The real decision happens one capability at a time.
What follows is a way to make that decision deliberately rather than by default, with the cost mathematics, the risks on each side, and the German market specifics that change the answer.
Two different bets
Buying standard software is a bet that your requirement is common. You are paying a share of a product that thousands of companies fund together, which is why a Warenwirtschaft licence costs less than a fortnight of development. The vendor amortises research, security work and regulatory updates across their whole customer base.
Building custom software is a bet that your requirement is not common, or that the difference matters enough to pay for. You carry the full development cost and the full maintenance obligation, and in return the system does exactly what your process needs.
Both bets can be wrong. Companies buy standard products for genuinely unusual processes and then spend three years building workarounds around them. Companies build custom tools for problems a 40 euro per month subscription solves better. The failure mode in each direction is the same: nobody checked whether the requirement was actually distinctive.
Where standard software is hard to beat
Regulatory maintenance is the strongest argument, and German companies felt it recently with the E-Rechnung obligation. When mandatory electronic invoicing arrived, users of established accounting products received XRechnung and ZUGFeRD support as an update. Companies with self-built invoicing had to specify, build and test the format themselves. Standard vendors absorb this kind of change continuously: DATEV export changes, VAT rate adjustments, GoBD interpretation shifts.
Security is comparable. A widely deployed product has thousands of installations attracting scrutiny, a disclosure process and a patch cadence. Your internal tool has whoever remembers to update the dependencies.
There is also a hiring advantage that rarely gets mentioned. A new controller who has used SAP or Datev before is productive in weeks. A new controller facing your bespoke system needs training from the two colleagues who understand it, and if both leave, so does the knowledge.
For commodity functions, meaning anything where doing it differently gains you nothing, standard software is simply the better economic choice.
Where custom development earns its cost
The counterargument shows up in three situations.
The first is process differentiation. If your quoting logic, your scheduling model or your pricing rules are the reason customers choose you, encoding them in someone else’s product means constraining them to that vendor’s assumptions. A Sondermaschinenbau firm whose configurator handles thousands of valid variant combinations will not find that in a standard catalogue tool.
The second is integration density. Once a process spans four systems, the value sits in the connections rather than in any single application. Standard products are designed as destinations, not as connective tissue, and this is where firms offering Softwareentwicklung Deutschland do much of their work: building the layer that makes an MES, an ERP and a customer portal behave as one process rather than three.
The third is licence scaling. Per-seat pricing behaves harmlessly at twenty users and painfully at four hundred. A tool at 45 euro per user per month costs 216,000 euro over five years for 80 users. That number sits in the same range as building something you own outright, and the comparison shifts further each time the vendor raises prices.
Running the cost comparison honestly
The usual mistake is comparing a licence fee against a development quote. Compare five year totals instead.
For standard software, count licences, implementation and configuration effort, training, integration work to connect it to your existing systems, and expected price increases. Vendors rarely hold pricing flat across a five year horizon, and migration away from an entrenched system is expensive enough that renewal negotiations are not symmetrical.
For custom software, count the build, annual maintenance at 15 to 20 percent of the build cost, hosting, and internal time for requirements and testing. Add the risk premium for a project that may take longer than planned.
The crossover point depends heavily on user count. Below roughly 25 users, standard software almost always wins on cost. Above 100 users with a genuinely specific process, custom frequently wins. In between, the answer turns on how much configuration effort the standard product needs, since a heavily customised standard system can end up costing more than a purpose-built one while retaining all the constraints of the original.
The risks nobody puts in the business case
Standard software carries vendor dependency. The product roadmap belongs to the vendor, not to you. Features you rely on can be deprecated, pricing models can change from perpetual to subscription, and the vendor can be acquired by a company with different priorities. Data export capability is worth checking before signing rather than after.
Custom software carries continuity risk. Systems built once and never touched accumulate outdated dependencies until an upgrade becomes a rewrite. If a single developer holds the knowledge, that is an operational risk regardless of how well the code is written. The mitigations are unglamorous: documentation standards, code in your own repository, and a named party responsible for maintenance.
Neither risk is a reason to avoid a choice. Both are reasons to write specific contract and process terms around it.
Data sovereignty as a deciding factor
For some German companies this settles the argument on its own.
Standard SaaS products frequently process data on infrastructure operated by US providers, which brings transfer mechanisms, sub-processor chains and Schrems II considerations into scope. Many organisations manage this without difficulty.
Others cannot, particularly in healthcare, public administration and parts of the financial sector, where tenders may require German hosting and a demonstrable processing chain.
When those constraints are firm, the shortlist of standard products shrinks quickly, and custom development on infrastructure you control becomes the practical option rather than the ambitious one.
Providers such as IIHGlobal Germany treat EU hosting and Auftragsverarbeitung documentation as baseline requirements, which is worth confirming early, because retrofitting data residency into a live system is rarely a small change.
The answer is usually both
Most well-run application landscapes follow the same pattern. Standard products handle finance, HR, email and CRM. Custom development handles the operational core and the integration layer between everything else.
A useful test: if a competitor bought the identical software, would anything change? For payroll, no. For the system that schedules your production line around customer priorities, yes. Buy the first category, build the second, and accept that the boundary moves over time as vendors catch up with what was once distinctive.
A middle path deserves mention too. Extending a platform through its own APIs, or configuring a low-code environment, sits between the two options and often gives most of the benefit for a fraction of the cost. It works well until the platform’s limits become the process’s limits, which happens more suddenly than expected.
Getting to a decision
Start by listing your processes and marking each one as commodity or differentiating. Be strict, since most companies overestimate how unusual they are. Then, for anything marked differentiating, check whether a standard product genuinely covers it or merely covers something adjacent.
Where custom looks justified, get a discovery phase scoped before requesting full quotes. Two to four weeks of analysis converts a vague intention into a specification and a defensible estimate. Teams working in Softwareentwicklung in Berlin and other major hubs offer this as a standalone engagement, which lets you test the working relationship before committing a full budget.
The decision that ages worst is the one made to avoid deciding, where a standard product is bought because it is faster and the workarounds are treated as temporary. Five years later those workarounds are the process, and unwinding them costs more than building properly would have.
