Häufig gestellte Fragen
What is custom software?
Custom software is an application developed exclusively for the requirements of a single client rather than bought as a ready-made off-the-shelf product. It maps business processes, data models and user interfaces exactly as the client needs them and is therefore one of a kind. In contrast to standard software, which serves a broad market with largely identical functions, custom software generally cannot be readily transferred to other companies. Synonymous terms include tailor-made software, in-house development, and custom or bespoke software.
What is the difference between custom and standard software?
Standard software is a finished product for many customers, used against a licence or subscription fee, with a fixed scope of functions maintained by the vendor. Custom software, by contrast, is developed once for exactly one client and is aligned entirely with that client's processes. Standard software scores with lower initial costs, quick availability and vendor-provided updates, but typically covers only the majority of requirements; the remaining, often differentiating special processes do not always fit the mould. Custom software offers maximum fit here, but in return requires higher upfront investment and the client's own responsibility for maintenance and further development.
What does custom software cost?
A blanket figure is not credible without specific requirements, since functional scope, interfaces and quality standards determine the costs. Hourly rates of qualified development providers in the German-speaking region typically lie at around 100 to 180 euros, so manageable mid-market projects often start in the five-figure range, while extensive, highly integrated ERP-adjacent solutions can easily reach six to seven figures. On top of this come ongoing costs for operation, maintenance and further development, for which, depending on the source, roughly 15 to 25 percent of the development costs per year should be budgeted. What matters is therefore a view of total costs across the life cycle, not just the initial build price.
When is custom software worthwhile in the ERP context?
As a complete replacement for an ERP system, a full in-house development is rarely worthwhile, because established standard systems cover purchasing, warehousing, finance and similar cross-functional areas in a proven and well-maintained way. Custom software makes sense above all where a process constitutes a genuine competitive advantage or is so specific that no standard solution fits. In practice, a middle path usually proves best: a standard ERP as a stable foundation plus targeted custom extensions via the vendor's customising options, low-code platforms or dedicated modules connected via interfaces. This keeps standard functions upgrade-capable, while only the truly differentiating areas are built individually.
Who owns the source code and what is the legal situation with custom software?
In Germany, the creation of custom software is legally classified predominantly as a contract for work under Sections 631 et seq. BGB, under which a specific, acceptable work product is owed. Copyright itself remains with the developer and is not transferable; through the contract, the client merely receives usage rights, the scope of which should be regulated explicitly. Without a clear agreement, the handover of the source code in particular is not automatically owed, which is why points such as exclusivity, modification and transfer rights, and source code delivery should be fixed contractually. For defects, a warranty period of two years from acceptance of the work generally applies under Section 634a BGB.
What risks does custom software entail for maintenance and updates?
Since no one else uses the same solution, responsibility for bug fixing, security updates and further development rests permanently with the company or its service provider, rather than with the vendor of a standard solution. Heavily individualised modifications can also jeopardise release capability: deep interventions make later version upgrades more difficult and may have to be laboriously rebuilt when switching ERP systems. There is also the risk of dependence on individual people or service providers if their know-how is not documented. These risks can be reduced considerably through clean documentation, clearly regulated responsibilities and an interface-based separation of standard and custom development wherever possible.