Standard Software vs Custom Software: Decision Matrix and TCO Logic

Standard software vs custom software is not a matter of principle for the whole company, it is a decision taken process by process. For most processes in an industrial plant standard software wins; for the few that set the plant apart from its competitors, custom software is often the objectively better choice. This article gives you the matrix for that decision - with five-year TCO logic, the question of rights, and the accounting treatment.

Standard software vs custom software: what really separates the two

The difference between standard software and custom software is not one of quality but of who dictates the process: with standard software the vendor does, for many customers at once; with custom software the client does, for a single plant. Everything else - cost structure, rights, operation, dependencies - follows from that one point.

Standard software

A product that a vendor develops, maintains and licenses for a market. The customer adopts the process built into the product and adapts through configuration. Examples: ERP, financial accounting, CAD, office suites.

Custom software

Software built for the requirements of exactly one client - by in-house staff or a contracted developer. The process defines the software, not the other way round. Examples: set-up planning for a specific machine fleet, inspection records to a specific customer specification.

Customising / parameterisation

Adapting standard software through the settings, fields and workflows the product provides. It stays inside the product logic and usually survives release upgrades.

Add-on / extension

Additional code written against the extension points of a standard product. It extends the product logic and has to be retested after every vendor release.

Hybrid architecture

Standard software as the leading system for master data and postings, a custom application for the differentiating process, and a defined interface in between.

In practice the pure either/or question is rare. A standard ERP with five years of customising history and three add-ons is effectively a custom system that also carries licence fees - only without the rights and the documentation of an in-house build. The question is therefore never 'standard software or custom software for the company?' but 'which process belongs in which category?'.

When standard software clearly wins

Standard software wins whenever the process does not belong to you but to the legislator, a standard or the market. Individuality is not an advantage there, it is a risk: you would have to follow every change in the law and every new data format yourself, while a vendor maintains the same change once for all of its customers.

The German e-invoicing obligation is a current example. For domestic B2B supplies, Section 14 UStG (the German VAT Act) requires an electronic invoice in a structured format that complies with the European standard on electronic invoicing under Directive 2014/55/EU (EN 16931). The transitional rule in Section 27 (38) UStG allows paper or other electronic formats only for supplies made up to 31 December 2026; companies with prior-year turnover of up to EUR 800,000 have until 31 December 2027. A format like this is maintained by a vendor for tens of thousands of customers - implement it yourself and you carry every change alone.

When custom software is the objectively better choice

Custom software is the objectively better choice in exactly four situations - and each of them can be established with a single test question before any quote is requested. If none of the four applies, the discussion is over.

The pros and cons of custom software belong on one sheet of paper, soberly stated: fit, rights to the code, no per-user licence and changes on your own cadence on one side - lead time, dependency on the developer and self-organised operation on the other. None of that settles the question on its own; the four test questions in Table 02 do, applied to one process at a time.

The decision matrix: eight weighted criteria

The decision matrix translates the four situations into a scoring grid that the department, IT and procurement fill in independently of each other. Each criterion gets 1, 2 or 3 points and a fixed weight: 1 argues for standard software, 3 for custom software. The weights add up to 20, so the result lies between 20 and 60 points.

Scoring rule: points times weight, then add everything up. Up to 32 points, standard software is settled. Between 33 and 44 points it is worth examining a hybrid architecture. From 45 points, obtain a quote for custom development - in parallel with a quote for adapting the best standard product. The thresholds are rules of thumb, not a norm; fix them before you start scoring. Wherever the three assessments differ by two points, the requirement is unclear and belongs in the specification.

Worked example with fictitious figures: a supplier scores tool and set-up management across fourteen presses. Process individuality 3 (12 points), rate of change 2 (4), number of users 1 (2), depth of integration 3 (9), data sovereignty 2 (4), audit obligations 2 (4), budget 2 (4), in-house operating capability 2 (6). Total: 45 points, just inside the custom range - a case where hybrid and custom quotes should be compared side by side. The same plant scores its time recording: 1, 1, 2, 1, 1, 2, 2, 1 gives 26 points. Standard, with no further discussion.

The operating-capability criterion is routinely underestimated. Custom software needs someone who writes the requirements, tests releases and owns operations - and that person is hard to find: according to Bitkom Research, around 79,000 IT specialists were missing across the German economy in calendar weeks 18 to 25 of 2026, with IT administration and systems operations the most sought-after skill set at 26%.

Total cost of ownership over five years: the calculation rarely made

Most comparisons stop at licence price versus development quote. The calculation that matters runs over 60 months and has seven cost blocks - on both routes. Anyone who does not set them all out is comparing the base of one option with the curve of the other.

Two blocks are almost always missing: the release rework on standard software, whose cadence the vendor sets, and the exit costs on both routes. The shape of the curves is quickly described: with standard software costs grow with user numbers and time, with custom software a high base comes first and a flat curve after it. Where the two cross depends on user numbers, depth of integration and the period considered. Hourly rates, project sizes and the hidden cost drivers with market data are covered in What does custom software cost in industry?; this article stays with the arithmetic.

Who owns the software? Rights, source code and lock-in

Paying for custom software does not automatically mean owning it. Under Section 69c UrhG (the German Copyright Act), the rightholder has the exclusive right to reproduce, translate, adapt and distribute a computer program. Who that rightholder is, and which rights you receive, is settled by the contract - not by the invoice you paid. Without an explicit clause you may hold no more than a non-exclusive right of use, with no permission to modify the code or pass it to another service provider.

Both routes create dependency, only on different parties. With standard software the lifecycle belongs to the vendor: in February 2020 SAP announced mainstream maintenance for the core applications of SAP Business Suite 7 until the end of 2027, with optional extended maintenance until the end of 2030 at a premium of two percentage points on the existing maintenance base. That is not a criticism of SAP but the mechanics of every standard product. With custom software the dependency sits with the developer - with their knowledge, their documentation and their availability five years from now.

The accounting view: capitalisation, depreciation, useful life

For tax purposes what counts is whether software was produced in-house or acquired. Section 5 (2) EStG (the German Income Tax Act) provides that an asset may be recognised for intangible fixed assets only where they were acquired for consideration. Software developed by your own staff is therefore not capitalised in the tax balance sheet; the development costs are an expense of the period. The commercial balance sheet grants an option instead: under Section 248 (2) HGB (the German Commercial Code), internally generated intangible fixed assets may be recognised as an asset.

For acquired software, the BMF-Schreiben of 22 February 2022 (ref. IV C 3 - S 2190/21/10002 :025), the German Federal Ministry of Finance circular that replaced the one of 26 February 2021, applies. It allows a useful life of one year for operating and application software used for data entry and processing. Margin number 5 includes applications tailored to the individual user, such as ERP software, merchandise management systems and other application software for business administration or process control. It also states that this shorter useful life is neither a special form of depreciation, nor a new depreciation method, nor an immediate write-off, and is not an election within the meaning of Section 5 (1) EStG, that taxpayers may depart from it, and that full depreciation in the year of acquisition is not challenged.

The third route: standard at the core, custom at the edges

The most common outcome of a proper assessment is neither standard nor custom but both, with a clear boundary: the ERP stays the system of record for master data, orders and postings, a custom application takes over the one differentiating process, and a defined interface sits between them.

• —Everything that is posted, invoiced, reported or expected by auditors stays in the standard product.
• —Everything that runs at the cadence of production, needs machine data or looks different for every customer moves outside it.
• —Every piece of information has exactly one leading system; the custom application reads master data but writes none back that the ERP maintains itself.
• —The interface gets an owner, a version number and a test case per data flow - and the integration effort gets a cost block of its own in the TCO.

The boundary almost always runs where the ERP is being propped up with Excel lists and side calculations. That is exactly where the process specific to your plant sits. How to tackle it on the shop floor without touching the ERP is described in Process automation in manufacturing: the smallest sensible first step.

Five steps to the decision

1. 01

   Isolate the process

   Describe the one process on a single page with its trigger, participants, systems, data objects and result. Whatever does not fit on that page is two processes.

2. 02

   Screen the market with knock-out criteria

   Define three to five knock-out criteria - on-premise capability, PLC connectivity, data export - and strike out everything that fails them before the first demo.

3. 03

   Test two or three standard products properly

   Test with your own data and your ten most frequent cases, not with the supplier's demo data set. Note every gap and whether it can be closed by configuration, by an add-on, or not at all.

4. 04

   Have the adaptation effort quantified

   Ask for a written quote covering customising and add-ons for those gaps - including release maintenance over five years. Only that figure makes situation 4 from Table 02 testable.

5. 05

   Only now request a custom quote

   On the basis of a requirements specification that emerges from steps 1 to 4. Without that document the quotes are not comparable, and every later clarification turns into a change request.

Conclusion

Standard software vs custom software is decided process by process, and in most processes the standard product wins - because the legislator, a standard or the market dictates the sequence. Custom software belongs at the few points that set a plant apart, that no product covers, whose data must stay in-house, or whose adaptation on the standard product would cost more than building new. The matrix, the TCO formula and the contract list make that boundary visible before a supplier draws it for you.

The next step is not a quote but a completed matrix for the one process that costs you the most effort. If the result lands in the custom or hybrid range, an assessment of architecture and interfaces before the specification is worthwhile - for example as part of custom software development at ralwo.